Network Working Group S. Ooghe Internet-Draft Alcatel Expires: July 5, 2006 N. Voigt Siemens M. Platnic ECI T. Haag T-Systems January 2006 Framework and Requirements for a Layer 2 Control Protocol (L2CP) in Broadband Multi-Service Networks draft-ooghe-l2cp-framework-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The purpose of this document is to define a framework for a Layer 2 Control Protocol (L2CP) mechanism between a service-oriented layer 3 Ooghe, et al. Expires July 5, 2006 [Page 1] Internet-Draft L2CP Framework January 2006 edge device (e.g. a BRAS) and a layer 2 Access Node (e.g. a DSLAM) in a multi-service architecture. This mechanism allows to perform QoS- related, service-related and subscriber-related operations. The Layer 2 Control mechanism ensures the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This document does not specify design requirements for network elements. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. General Design Aspects . . . . . . . . . . . . . . . . . . . . 4 2.1. Concept of a Layer 2 Control Plane . . . . . . . . . . . . 4 2.2. Reference Architecture . . . . . . . . . . . . . . . . . . 5 2.2.1. Home Gateway . . . . . . . . . . . . . . . . . . . . . 6 2.2.2. Access loop . . . . . . . . . . . . . . . . . . . . . 6 2.2.3. Access Node . . . . . . . . . . . . . . . . . . . . . 6 2.2.4. Access Node uplink . . . . . . . . . . . . . . . . . . 6 2.2.5. Aggregation Network . . . . . . . . . . . . . . . . . 7 2.2.6. Broadband Network Gateway . . . . . . . . . . . . . . 7 2.3. Operation and Management . . . . . . . . . . . . . . . . . 7 2.3.1. Port Addressing Scheme . . . . . . . . . . . . . . . . 7 3. Layer 2 Control use cases . . . . . . . . . . . . . . . . . . 9 3.1. Access Topology Discovery . . . . . . . . . . . . . . . . 9 3.2. Line Configuration . . . . . . . . . . . . . . . . . . . . 9 3.3. OAM in a mixed ATM/Ethernet Environment . . . . . . . . . 10 3.4. OAM in Ethernet Layer 2 Context . . . . . . . . . . . . . 11 3.5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Policy Server Interaction . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Ooghe, et al. Expires July 5, 2006 [Page 2] Internet-Draft L2CP Framework January 2006 1. Introduction DSL technology is widely deployed for Broadband Access for Next Generation Networks. Several documents including DSL Forum TR-058 [TR-058] and DSL Forum TR-059 [TR-059] describe possible architectures for these access networks. Also, with the rise of supporting more bandwidth hungry services such as IPTV, architectures based on Ethernet access/aggregation get increasingly important (work on these architecture concepts are nearing completion at the DSL Forum). In the scope of these architectures is the delivery of voice, video and data services. The framework defined in this document is focused on the control interaction between network elements and mainly targeted at DSL based access (either by means of ATM over DSL or as Ethernet over DSL); however the framework is open to non-DSL technologies, like PON, FTTx and WiMAX. Traditional architectures require permanent ATM virtual circuit(s) per subscriber. Such a virtual circuit is configured on layer 2 and terminated at the first layer 3 device (e.g. BRAS). Beside the data plane, the models define the architectures for element, network and service management. But due to organizational boundaries between departments operating the access loop, departments operating the ATM network, and departments operating the IP network, interworking at the management plane is not always possible. Besides, management networks are usually not designed to transmit management data between the different entities in real time. When deploying value-added services across DSL access networks, special attention regarding Quality of Service and service control is required, which implies a tighter coordination between network nodes (e.g. Access Nodes and Broadband Network Gateway), without burdening the OSS layer with unpractical expectations. 1.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Ooghe, et al. Expires July 5, 2006 [Page 3] Internet-Draft L2CP Framework January 2006 2. General Design Aspects In this section first the concept of the Layer 2 Control Plane is described. Then, the reference network is described where the Layer 2 Control Plane is introduced. 2.1. Concept of a Layer 2 Control Plane The high-level communication framework for a Layer 2 Control Plane is defined in Figure 1. The Layer 2 Control Plane defines a general- purpose mechanism for multiple network scenarios with an extensible communication scheme, addressing the different use cases that are described throughout this document. Information Reports --------------------------> Control Requests <-------------------------- Control Replies --------------------------> +-----+ +-----+ +--------+ +-----+ | CPE |---| HGW |---| | | | +-----+ +-----+ | Access | +---------+ | | +--------+ | Node |---| Aggreg. |---| BNG |---| Policy | +-----+ +-----+ | | | Node | | | | Server | | CPE |---| HGW |---| | +---------+ | | +--------+ +-----+ +-----+ +--------+ +-----+ Layer 2 Control Plane <-------------------------> PPP, DHCP, IP <---------><-------------------------------------> Figure 1 From a functional perspective, a number of functions can be identified: o A controller function: this function is used to either send out requests for information to be used by the network element where the controller function resides, or to trigger a certain behavior in the network element where the reporting and/or enforcement function resides; Ooghe, et al. Expires July 5, 2006 [Page 4] Internet-Draft L2CP Framework January 2006 o A reporting and/or enforcement function: the reporting function is used to convey status information to the controller function that requires the information for executing local functions. An example of this is the transmission of an access loop rate from an Access Node to a Broadband Network Gateway (BNG) tasked with shaping traffic to that rate. The enforcement function is contacted by the controller function to trigger a local action. An example of this is the initiation of a port testing mechanism on an Access Node. The connectivity between the Access Node and the BNG may differ depending on the actual layer 2 technology used (ATM or Ethernet). Therefore the identification of unicast & multicast flows/channels will also differ (see also Section 2.3.1). The control plane interactions are transactional in nature and imply a reliable communication channel to share states. Bidirectional operations are needed, as well as dynamic negotiation of capabilities to address transition issues. The use cases in this document are described in an abstract way, independent from any actual protocol mapping. The actual protocol specification is out of scope of this document, but there are certain characteristics of the protocol required such as to simplify specification, implementation, debugging & troubleshooting, but also to be easily extensible in order to support additional use cases. 2.2. Reference Architecture The reference architecture used in this document can be based on ATM or Ethernet access/aggregation. Specifically: o In case of a legacy ATM aggregation network that is to be used for the introduction of new QoS-enabled IP services, the architecture builds on the reference architecture specified in DSL Forum TR- 059; o In case of an Ethernet aggregation network that supports new QoS- enabled IP services (including Ethernet multicast replication), the architecture builds on the Ethernet bridging/switching concepts defined in IEEE 802, combined with a number of protocol operations (PPPoE, DHCP, ARP, IGMP), security extensions and multicast operation that is being worked out by the DSL Forum (work on these architecture concepts are nearing completion). Given the industry's move towards Ethernet as the new access and aggregation technology for triple play services, the primary focus throughout this document is on Ethernet access/aggregation. However Ooghe, et al. Expires July 5, 2006 [Page 5] Internet-Draft L2CP Framework January 2006 the concepts are equally applicable to an ATM architecture based on TR-059. The Layer 2 Control mechanism MUST be defined in a way that is independent of the underlying layer 2 transport technology. Specifically, the Layer 2 Control mechanism MUST support transmission over an ATM as well as over an Ethernet aggregation network. 2.2.1. Home Gateway The Home Gateway (HGW) connects the different Customer Premises Equipment (CPE) to the Access Node and the access network. In case of DSL, the HGW is a DSL modem that could either operate as a layer 2 bridge or as a layer 3 router. In the latter case, such a device is also referred to as a Routing Gateway (RG). 2.2.2. Access loop The access loop ensures physical connectivity between the Network Interface Device (NID) at the customer premises, and the Access Node. Legacy protocol encapsulations use multi-protocol encapsulation over AAL5, defined in RFC2364. This covers PPP over Ethernet (PPPoE, defined in RFC2516), bridged IP (IPoE) and routed IP (IPoA, defined in RFC2225). Next to this, PPPoA as defined in RFC2364 can be used. Future scenarios include cases where the access loop supports direct Ethernet encapsulation (e.g. when using VDSL). 2.2.3. Access Node The Access Node is a network element that terminates the access loops. It supports one or more access loop technologies and allow them to inter-work with a common aggregation network technology. For example, an access node can support ADSL2+, VDSL2 and BPON as access loop types and then backhaul the data to the aggregation network using Ethernet. There is an emerging requirement that Access Nodes support multiple access loop technologies, rather than only one. The framework defined by this document is targeted at DSL based access (either by means of AAL5/ATM/DSL or as Ethernet/DSL); however the framework is open to non-DSL technologies, like PON, FTTx and WiMAX. The reporting and/or enforcement function defined in Section 2.1 typically resides in an Access Node. 2.2.4. Access Node uplink The fundamental requirements for the Access Node uplink are to Ooghe, et al. Expires July 5, 2006 [Page 6] Internet-Draft L2CP Framework January 2006 provide traffic aggregation, Class of Service distinction and customer separation and traceability. This can be achieved using an ATM or an Ethernet based technology. 2.2.5. Aggregation Network The aggregation network provides traffic aggregation towards the BNG(s). The aggregation technology can be based on ATM (in case of a TR-059 architecture) or Ethernet (cf. the architecture work performed by the DSL Forum). 2.2.6. Broadband Network Gateway The Broadband Network Gateway (BNG) is an IP Edge Router where bandwidth and QoS policies may be applied. The BRAS is a specific BNG that provides aggregation capabilities (e.g. IP, PPP, Ethernet) between the access network and the Network Service Provider or Application Service Provider. Beyond aggregation, it is also an injection point for policy management and IP QoS in the access network. The BNG interfaces to the aggregation network by means of standard ATM or Ethernet interfaces, and towards the regional broadband network by means of transport interfaces for Ethernet frames (e.g. GigE, Ethernet over SONET). The BNG supports the Layer 2 Control functionality defined for the respective use cases throughout this document. The controller function defined in Section 2.1 typically resides in a BNG. 2.3. Operation and Management When introducing a Layer 2 Control Plane, care is needed to ensure that the existing management mechanisms remain operational as before. Specifically when using the Layer 2 Control Plane for performing a configuration action on a network element, one gets confronted with the challenge of supporting multiple managers for the same network element: both the Element Manager as well as the Layer 2 Controller function may now perform configuration actions on the same network element. Conflicts therefore need to be avoided. Also, when using the Layer 2 Control Plane for performing a reporting action, there is a possibility to integrate this with a central Policy Management system that keeps track of the different subscriber related parameters (e.g. access loop bitrate). 2.3.1. Port Addressing Scheme In deployments using an ATM aggregation network, access loop identification is facilitated by the typical one-to-one mapping Ooghe, et al. Expires July 5, 2006 [Page 7] Internet-Draft L2CP Framework January 2006 between an access loop and ATM PVC between the Access Node and the BNG. Based on such property, in a PPP scenario, the BNG typically includes a NAS-Port-Id (or NAS-Port in some cases) attribute in RADIUS authentication & accounting packets sent to the RADIUS server(s). Such attribute includes the identification of the ATM VC for this subscriber, which allows in turn identifying the access loop. In an Ethernet based aggregation network, two different port addressing schemes can be used (cf. the architecture work performed by the DSL Forum): o A first approach is to use a one-to-one VLAN assignment model for all DSL ports. This allows the access loop identification to be directly derived from the VLAN tagging, i.e. S-VLAN ID or pair, of the frames coming from this DSL port; o A second approach is to use a many-to-one VLAN assignment model and to encode the access loop identification in the "Agent Circuit ID" sub-option to be added to a DHCP or PPPoE message. The details of this approach are being specified by the DSL Forum. This document assumes that the port addressing scheme should be based on what will be specified by the DSL Forum. It should be noted however that the use of such a scheme does not imply the actual existence of a PPPoE or DHCP session, nor on the specific interworking function present in the Access Node. In some cases, no PPPoE or DHCP session may be present, while the port addressing would still be desirable. Ooghe, et al. Expires July 5, 2006 [Page 8] Internet-Draft L2CP Framework January 2006 3. Layer 2 Control use cases 3.1. Access Topology Discovery TR-059 identifies various queuing/scheduling mechanisms to avoid congestion in the access network while dealing with multiple flows with distinct QoS requirements. Such mechanisms require that a BNG (e.g. a BRAS) gains knowledge about the topology of the access network, the various links being used and their respective rates. Some of the information required is somewhat dynamic in nature (e.g. DSL sync rate), hence cannot come from a provisioning and/or inventory management OSS system. Especially, when the access loop is operated in Rate Adaptive Mode (RAM) it is very important to enforce consistency of such data. When using an Ethernet-based aggregation network, there is no longer a "logical circuit" or "logical path" terminated on the layer 3 device (e.g. BNG), as a representation of the access loop. That creates in turn some challenges to properly configure the BNG and its hierarchical scheduler. Dynamic and automated discovery of the access network topology addresses these issues. The control plane allows the Access Node (e.g. DSLAM) to communicate to the BNG access network topology information and any corresponding updates. Topology Discovery is specifically important in case the data rate of the access loop changes overtime. Topology Discovery may actually include more information than link identification and corresponding data rates, notably for the access loop such as Interleaving Delay or Minimum and Maximum attainable rates. The topology and the rates of the various links to enable the BNG hierarchical scheduling and policing mechanisms are the following: o The identification and speed (rate) of the access loop (DSL sync rate) o The identification and speed (rate) of the Remote Terminal/Access Node link (when relevant) The BNG can adjust downstream shaping to current access loop rate, and more generally re-configure the appropriate nodes of its hierarchical scheduler. 3.2. Line Configuration Access loop rates are typically configured in a static way. If a Ooghe, et al. Expires July 5, 2006 [Page 9] Internet-Draft L2CP Framework January 2006 subscriber wants to change its access loop rate, this requires a reconfiguration of the access loop via the network operator, possibly implying a business-to-business transaction between an Internet Service Provider and an Access Provider. A Layer 2 Control mechanism supports a more flexible approach for supporting "bandwidth on demand". Triggered by topology information as assisted by Access Topology Discovery described in Section 3.1, the BNG could query a policy server (e.g. RADIUS server) to retrieve line configuration data. Most of the subscriber related service configuration is typically enforced at the BNG, but there are a few cases where it can be useful to push such service parameters to the Access Node for local enforcement of a mechanism (e.g. DSL related) on the corresponding access loop. The BNG may send line configuration information to the Access Node using Subscriber Request messages. The BNG may also update the line configuration due to a subscriber service change (e.g. triggered by the policy server). Using a Layer 2 Control plane, the BNG achieves such goal by an interoperable and standardized protocol. Using such approach simplifies the OSS infrastructure for service management, allowing to fully centralize subscriber-related service data (e.g. RADIUS server back-end) and avoiding complex cross- organization business-to-business interactions. More generally, several service/subscriber DSL parameters (e.g. rate, inter-leaving delay) can benefit from such flexible approach to enable a "service on demand" model. One way to change line parameters is by using profiles. These profiles (DSL profiles for different services) are pre-configured by the Element Manager that is managing the Access Nodes. The Layer 2 Control interaction then only needs to transmit a reference to the right DSL profile. Another way to change line parameters is by conveying discrete DSL parameters in the Layer 2 Control interaction. 3.3. OAM in a mixed ATM/Ethernet Environment Traditionally, ATM circuits are point to point connections between the BNG and the DSLAM or modem. In order to test the connectivity on layer 2, appropriate OAM functionality is used for operation and troubleshooting. By migrating to Ethernet-based aggregation networks, such ATM OAM functionality is no longer applicable. From an operator's point of view, it is still required to keep the same ways to test and troubleshoot connectivity in such a mixed Ethernet and ATM access network (including the access loop). Corresponding control plane functions must be envisioned. In an existing ATM architecture an end to end OAM loopback is performed between the edge devices (BRAS and modem/RG) of the access network. To reach Ooghe, et al. Expires July 5, 2006 [Page 10] Internet-Draft L2CP Framework January 2006 consistency in the operation of the access network, an appropriate functionality must be implemented. A Layer 2 Control plane between BNG and Access Node can close the gap which currently occurs by migrating to Ethernet, until appropriate native Ethernet OAM standard mechanisms are ratified. Triggered by a local management interface, the BNG can initiate a loop test between Access Node and modem/RG via a Layer 2 Control operation. A Subscriber Request is sent to the Access Node, which triggers on the access loop either an ATM F5 loopback test in case of sending ATM cells over the access loop, or a port synchronization and administrative test in case of sending Ethernet frames over the access loop. A Subscriber Response is sent by the Access Node to the BNG, which may report results via a local management interface. Thus, the connectivity between the BNG and the modem/RG can be monitored by a single trigger event. 3.4. OAM in Ethernet Layer 2 Context From an operator's point of view, once Ethernet technology is used between the BNG and the modem/RG, similar end-to-end OAM mechanisms are desired as used to be applied by ATM OAM. Unfortunately there is no comparable data structure for Ethernet-based Access Nodes because the OAM mechanisms based on IEEE802.3ah or IEEE802.1ag are still being discussed. When Ethernet based VDSL2 access is present, a port status test triggered by the BNG EMS and conveyed via a Layer 2 Control Plane could be seen as workaround. 3.5. Multicast With the rise of supporting IPTV services in a resource efficient way, multicast services are getting increasingly important. This especially holds for an Ethernet based access/aggregation architecture. In such a model, typically IGMP is used to control the multicast content replication process. This is achieve by means of IGMP snooping or IGMP proxy in the different layer 2 nodes in the network (e.g. DSLAM, Ethernet aggregation switch). In such a context it needs to be seen if and how the Layer 2 Control Plane applies to such multicast based applications. Ooghe, et al. Expires July 5, 2006 [Page 11] Internet-Draft L2CP Framework January 2006 4. Policy Server Interaction This document does not consider the specific details of the communication with a policy server (e.g. using RADIUS). Ooghe, et al. Expires July 5, 2006 [Page 12] Internet-Draft L2CP Framework January 2006 5. Security Considerations This document does not consider additional security considerations. Ooghe, et al. Expires July 5, 2006 [Page 13] Internet-Draft L2CP Framework January 2006 6. Acknowledgements The authors would like to thank everyone that has provided comments or input to this document. In particular, the authors acknowledge the work done by the contributors to DSL Forum PD-021, which contains parts of the rationale described in this document. Ooghe, et al. Expires July 5, 2006 [Page 14] Internet-Draft L2CP Framework January 2006 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 7.2. Informative References [TR-058] Elias, M. and S. Ooghe, "Multi-Service Architecture & Framework Requirements", DSL Forum TR-058, September 2003. [TR-059] Anschutz, T., "DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services", DSL Forum TR- 059, September 2003. Ooghe, et al. Expires July 5, 2006 [Page 15] Internet-Draft L2CP Framework January 2006 Authors' Addresses Sven Ooghe Alcatel Francis Wellesplein 1 B-2018 Antwerp Belgium Phone: +32 3 240 42 26 Email: sven.ooghe@alcatel.be Norbert Voigt Siemens Siemensallee 1 17489 Greifswald Germany Phone: +49 3834 555 771 Email: norbert.voigt@siemens.com Michel Platnic ECI 30 Hasivim Street Petakh Tikva Israel Phone: + 972 3 926 85 35 Email: michel.platnic@ecitele.com Thomas Haag T-Systems Deutsche Telekom Allee 7 64295 Darmstadt Germany Phone: +49 6151 937 5347 Email: thomas.haag@t-systems.com Ooghe, et al. Expires July 5, 2006 [Page 16] Internet-Draft L2CP Framework January 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ooghe, et al. Expires July 5, 2006 [Page 17]