Working Group Name Jerome Moisand Internet Draft Juniper Networks Expires: August 2, 2005 Sanjay Wadhwa Juniper Networks Swami Subramanian Juniper Networks GSMP extensions for layer2 control (L2C) Topology Discovery and Line Configuration draft-wadhwa-gsmp-l2control-configuration-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.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 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 Dec 17, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Wadhwa et.al Expires December 2, 2005 [Page 1] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 Abstract This document describes proposed extensions to the GSMP protocol to allow its use in a broadband environment, as a control plane between Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. BRAS). This document focuses on specific use cases, topology discovery and line configuration. It is intended to be complemented by other Internet-drafts focusing on additional use cases. Conventions used in this document 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 RFC-2119 [1]. Table of Contents Table of Contents 2 1 Specification Requirements 4 2 Introduction 4 3 Broadband Access Aggregation 4 3.1 ATM-based broadband aggregation..........................4 3.2 Ethernet-based broadband aggregation (TBD)...............6 4 Layer2 Control Protocol 6 4.1 Overview.................................................6 4.2 Layer2 control for Access Topology Discovery.............7 4.2.1 Goals..............................................7 4.2.2 Message Flow - GSMP mapping........................8 4.3 Layer2 control for Line Configuration....................9 4.3.1 Goals..............................................9 4.3.2 Message Flow - GSMP mapping.......................10 4.4 Layer2 Control for Transactional Multicast..............12 5 GSMP for Layer2 Control Protocol 13 5.1 GSMP/TCP connection establishment.......................13 5.2 GSMP connection keep-alive..............................13 5.3 Capability negotiation..................................14 5.4 GSMP Message Extensions for L2 control..................16 5.4.1 Topology Discovery................................16 5.4.2 Line Configuration................................23 5.5 ATM-specific considerations.............................25 5.6 Ethernet-specific considerations .................26 Wadhwa et.al Expires December 2, 2005 [Page 2] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 5.7 Graceful restart considerations (TBD)...................27 6 IANA Considerations 27 7 Security Considerations 27 8 References 27 Author's Addresses 28 Intellectual Property Statement 28 Disclaimer of Validity 29 Copyright Statement 29 Acknowledgment 29 Wadhwa et.al Expires December 2, 2005 [Page 3] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 1 Specification Requirements 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 RFC 2119. 2 Introduction DSL is a widely deployed access technology for Broadband Access for Next Generation Networks. Several specifications like [1-3] describe possible architectures for these access networks. In the scope of these specifications are the delivery of voice, video and data services. 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 elements in the broadband access network without burdening the OSS layer. This draft defines extensions to GSMPv3 to be used as a control plane between a service-oriented layer 3 edge device (the BRAS) and a layer2 Access Node (e.g. DSLAM) in order to perform QoS-related, service-related and subscriber-related operations. 3 Broadband Access Aggregation 3.1 ATM-based broadband aggregation End to end DSL network consists of network and application service provider networks (NSP and ASP networks), regional/access network, and customer premises network. Fig 1. shows ATM broadband access network components. The NSP authenticates access and provides and manages the IP address to subscribers. It is responsible for overall service assurance and includes internet service providers. ASP provides application services to the application subscriber (gaming, video, content on demand, IP telephony etc.). Wadhwa et.al Expires December 2, 2005 [Page 4] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 The Regional/Access Network consists of the Regional Network, Broadband Remote Access Server, and the Access Network as show in Fig 1. Its primary function is to provide end-to-end transport between the customer premises and the NSP or ASP. The Regional/Access Network may also provide higher layer functions such as QoS and content distribution. The Regional Network connects one or more BRAS and associated Access Network to NSPs and ASPs. It supports aggregation of traffic from multiple Access Networks and hands off larger geographic locations to NSPs and ASPs – relieving a potential requirement for them to build infrastructure to attach more directly to the various Access Networks. The Access Node terminates the DSL signal. It could consist of DSLAM in the central office , or remote DSLAM, or a Remote Access Multiplexer (RAM). A DSLAM hub can be used in a central office to aggregate traffic from multiple remote physical devices, and is considered logically to be a part of the Access Node. Access node is the first point in the network where traffic on multiple DSL lines will be aggregated onto a single network. In an ATM access network, access Node is primarily an ATM concentrator, mapping PVCs from the DSL modem to PVCs in the ATM core. The BRAS performs multiple functions in the network. The BRAS is the aggregation point for the subscriber traffic. It provides aggregation capabilities (e.g. IP, PPP, ATM) between the Regional/Access Network and the NSP or ASP. These include traditional ATM-based offerings and newer, more native IP-based services. This includes support for Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet (PPPoE), as well as direct IP services encapsulated over an appropriate layer II transport. Beyond aggregation, BRAS is also the injection point for policy management and IP QoS in the Regional/Access Networks. In order to allow IP QoS support over an existing non-IP-aware layer 2 access network without using multiple layer 2 QoS classes, a mechanism based on hierarchical scheduling is used. This mechanism defined in [1], preserves IP QoS over the ATM network between the BRAS and the RGs by carefully controlling downstream traffic in the BRAS, so that significant queuing and congestion does not occur further down the Wadhwa et.al Expires December 2, 2005 [Page 5] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 ATM network. This is achieved by using a diffserv-aware hierarchical scheduler in the BRAS that will account for downstream trunk bandwidths and DSL synch rates. Routing Gateway is a customer premises functional element that provides IP routing and QOS capabilities. It may be integrated into or be separate from the modem. Access Customer <--- Aggregation ---> <------- Premises -------> Network Network +-------------------+ +--------------------------+ +----------+ +-----+ | +-----+ +------+ |--|+-----+ +--+ +----------+ | | | +-|BRAS |---| |ATM |--|Access| | ||DSL |-|RG|-|Subscriber| | NSP---+Regional | | +-----+ | +-----+ | Node | | ||Modem| +--+ |Devices | | |Broadband | | +-----+ | +------+ | |+-----+ +----------+ | |Network |-+-|BRAS | +---------------|---+ +--------------------------+ ASP---+ | | +-----+ | +--------------------------+ | | | +-----+ | | +-----+ +--+ +----------+| +----------+ +-|BRAS | +------| | DSL |-|RG|-|Subscriber|| +-----+ | |Modem| +--+ |Devices || | +-----+ +----------+| +--------------------------+ RG : Routing Gateway BRAS : Broadband Remote Access Server Fig.1 ATM Broadband Aggregation Topology 3.2 Ethernet-based broadband aggregation (TBD) 4 Layer2 Control Protocol 4.1 Overview There is a requirement for a control plane between service-oriented layer 3 edge device (the BRAS) and a layer 2 Access Node (e.g. DSLAM) in order to perform QoS-related, service-related and subscriber- related operations. A dedicated control protocol between BRAS and access nodes can fecilitate "BRAS managed" tight QOS control in the access network, simplified OSS infrastructure for service management, optimized multicast replication to enable video services over DSL, Wadhwa et.al Expires December 2, 2005 [Page 6] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 subscriber statistics retrieval on the BRAS for accounting purposes, and fault isolation capability on the BRAS for the underlying acccess technology. This document provides extensions to GSMPv3 [4] to implement layer2 control protocol. Following sections discuss the use of layer2 control protocol for implementing: . Dynamic discovery of access topology by the BRAS to provide tight QOS control in the access network. . Pushing to the access-nodes, subscriber and service data retrieved by the BRAS from an OSS system (e.g. radius server), to simplify OSS infrastructure for service management. . Optimized, "BRAS controlled and managed" multicast replication by access-nodes at L2 layer. In addition to DSL, alternate broadband access technologies (e.g. Metro-Ethernet, Passive Optical Networking, WiMax) will have similar challenges to address, and could benefit from the same approach of a control plane between a BRAS and an Access Node (e.g. OLT), providing a unified control and management architecture for multiple access technologies, hence facilitating migration from one to the other and/or parallel deployments. GSMPv3 is an ideal fit for implementing layer2 control protocol. It is extensible and can be run over TCP/IP, which makes it possible to run over different access technologies. 4.2 Layer2 control for Access Topology Discovery 4.2.1 Goals [1] discusses various queuing/scheduling mechanisms to avoid congestion in the access network while dealing with multiple flows with distinct QoS requirements. Such mechanisms require that the 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. Some of the information varies less frequently (e.g. capacity of a DSLAM uplink), but nevertheless needs to be kept strictly in sync between the actual capacity of the uplink and the image the BRAS has of it. Wadhwa et.al Expires December 2, 2005 [Page 7] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 OSS systems are rarely able to enforce in a reliable and scalable manner the consistency of such data, notably across organizational boundaries. Dynamic and automated discovery of the access network topology would help to address these issues, notably when performed by an interoperable and standardized protocol. Following section describes GSMPv3 messages that allow the Access Node (e.g. DSLAM) to communicate to the BRAS, access network topology information and any corresponding updates. Some of the parameters that can be communicated from the DSLAM to the BRAS include DSL line state, actual upstream and downstream data rates of a synchronized DSL link, maximum attainable upstream and downstream data rates, interleaving delay etc. Topology discovery is specifically important in case the net data rate of the DSL line changes over time. The DSL net data rate may be different every time the DSL modem is turned on. Additionally, during the time the DSL modem is active, data rate changes can occur due to environmental conditions (the DSL line can get "out of sync" and can retrain to a lower value. 4.2.2 Message Flow - GSMP mapping When a DSL line initially comes up or resynchronizes to a different rate, the DSLAM generates and transmits a GSMP PORT UP EVENT message to the BRAS. The extension field in the message carries the TLVs containing DSL line specific parameters. On a loss of signal on the DSL line, a GSMP PORT DOWN message is generated by the DSLAM to the BRAS. In order to provide expected service level, BRAS needs to learn the initial attributes of the DSL line before the subscriber can log in and access the provisioned services for the subscriber. The DSLAM SHOULD set "returnReceipt" result code in the EVENT messages to trigger an acknowledgement from the BRAS. <----- Port UP(EVENT Message) <----- DSL (default line parameters) Signal 1. BRAS ----------------------- DSLAM ----------- Routing ----- Subscriber Gateway <----- Port UP (EVENT Message) <----- DSL (updated line parameters) Resynch 2. BRAS ----------------------- DSLAM ----------- Routing ------ Subscriber Gateway Wadhwa et.al Expires December 2, 2005 [Page 8] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 <--- Port DOWN (EVENT Message) <---- DSL Loss of Signal 3. BRAS ---------------------- DSLAM ------------- Routing ----- Subscriber Gateway Fig 2. Message flow (GSMP mapping) for topology discovery The Event message with PORT UP message type (80) is used for conveying DSL line attributes to the BRAS. The format of extensions to the message is defined in section 5.4.1. 4.3 Layer2 control for Line Configuration 4.3.1 Goals Following dynamic discovery of access topology (identification of DSL line and it's attributes) as assisted by the mechanism described in the previous section (topology discovery), the BRAS could then query a subscriber management OSS system (e.g. RADIUS server) to retrieve subscriber authorization data (service profiles, aka user entitlement). Most of such service mechanisms are typically enforced by the BRAS itself, but there are a few cases where it might be useful to push such service parameter to the DSLAM for local enforcement of a mechanism (e.g. DSL-related) on the corresponding subscriber line. One such example of a service parameter that can be pushed to the DSLAM for local enforcement is DSL "interleaving delay". Longer interleaving delay (and hence stringent error correction) is required for a video service to ensure better video "quality of experience", whereas for a VoIP service or for "shoot first" gaming service, a very short interleaving delay is more appropriate. Another relevant application is downloading per subscriber multicast channel entitlement information in IPTV applications where the DSLAM is performing IGMP snooping or IGMP proxy function. Using GSMP, the BRAS could achieve the goal of pushing line configuration to the DSLAM by an interoperable and standardized protocol. If a subscriber wants to choose a different service, it can require an OPEX intensive reconfiguration of the line via a network operator, possibly implying a business-to-business transaction between an ISP Wadhwa et.al Expires December 2, 2005 [Page 9] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 and an access provider. Using L2C for line configuration from the BRAS dramatically simplifies the OSS infrastructure for service management, allowing fully centralized subscriber-related service data (e.g. RADIUS server back-end) and avoiding complex cross- organization B2B interactions. Therefore, proposed GSMP based line configuration support provides for more flexible approach for achieving "service on demand". More generally several service/subscriber DSL parameters (e.g. inter- leaving delay, rate etc.) could benefit from such flexible approach to enable a "service on demand" model. The best way to change line parameters would be by using profiles. These profiles (DSL profiles for different services) are pre- configured on the DSLAMs. The BRAS can then indicate a reference to the right DSL profile via GSMP. Alternatively, discrete DSL parameters can also be conveyed by the BRAS in GSMP. 4.3.2 Message Flow - GSMP mapping Triggered by topology information reporting a new DSL line or triggered by a subsequent user session establishment (PPP or DHCP), the BRAS may send line configuration information (e.g. reference to a DSL profile) to the DSLAM using Port Management messages. The BRAS may get such line configuration data from a policy server (e.g. RADIUS). Figure 3 summarizes the interaction. Wadhwa et.al Expires December 2, 2005 [Page 10] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 1.DSL Signal <----------- 2. Port UP (EVENT Message) (Access Topology Discovery) <-------------------------- 3. PPP/DHCP Session <----------------------------------------------------- 4. Authorization & Authentication <------------------- Port Management Message (Line Configuration) 5. ----------------> +-------------+ +-----+ +-------+ +----------+ +-----------+ |Radius/AAA |------|BRAS |---------| DSLAM |------ | Routing |------ |Subscriber | |Policy Server| +-----+ +-------+ | Gateway | +-----------+ +-------------+ +----------+ Fig 3. Message flow - GSMP mapping for Initial Line Configuration The BRAS may update the line configuration due to a subscriber service change (e.g. triggered by the policy server). Figure 4 summarizes the interaction. Wadhwa et.al Expires December 2, 2005 [Page 11] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 1. PPP/DHCP Session <------------------------------------------ +-------------+ 2. Service On Demand | |<------------------------------------------------ | Web portal | | OSS etc | 3.Change of 4.Port Management | | Authorization Message | Radius AAA | --------> (Updated Line | Policy | Config - New Profile) | | -------------. | | +------+ +-------+ +---------+ +----------+ | |----| BRAS |-----| DSLAM |---| Routing |--|Subscriber| | | +------+ +-------+ | Gateway | +----------+ +-------------+ +---------+ Fig 4. Message flow - GSMP mapping for Updated Line Configuration The format of extensions to port management message is defined in section 5.4.2. The line configuration models could be viewed as a form of delegation of authorization from the BRAS to the DSLAM. 4.4 Layer2 Control for Transactional Multicast Typical IP multicast in access networks involves the BRAS terminating user requests for receiving multicast channels via IGMP. The BRAS authorizes the subscriber, and dynamically determines the multicast subscription rights for the subscriber. Based on the user's subscription, the BRAS can replicate the same multicast stream to multiple subscribers. This leads to a waste of access bandwidth if multiple subscribers access network services via the same access-node (e.g. DSLAM). The amount of multicast replication is of the order of number of subscribers rather than the number of access-nodes. It is ideal for BRAS to send a single copy of the multicast stream to a given access-node, and let the access-node perform multicast replication by layer2 means (e.g. ATM point-to-multipoint cell replication or ethernet data-link bridging) for subscribers behind the access-node. However, operationally, BRAS is the ideal choice to handle subscriber management functions (authentication, authorization, accounting and address management), multicast policies such as per-channel authorization, and complex multicast routing Wadhwa et.al Expires December 2, 2005 [Page 12] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 protocols. Therefore, some means is needed for the BRAS to setup multicast replication state in the access-nodes. In ATM access networks, Layer2 control protocol can be used by the BRAS to setup P2MP cross-connects in the DSLAMs. GSMPv3 extensions for this use- case of layer2 control protocol will be provided in a separate ID [6]. 5 GSMP for Layer2 Control Protocol 5.1 GSMP/TCP connection establishment The L2 control protocol will use TCP for exchanging GSMP protocol messages. [5] defines the GSMP message encapsulation for TCP. The TCP session is initiated from the DSLAM (access node) to the BRAS (controller). This is necessary to avoid static provisioning on the BRAS for all the DSLAMs that are being served by the BRAS. It is easier to configure a given DSLAM with the single ip address of the BRAS that serves the DSLAM. This is a deviation from [5] which indicates that the controller initiates the TCP connection to the switch. BRAS listens for incoming connections from the access nodes. Port 6068 is used for TCP connection. Adjacency protocol messages, which are used to synchronize the BRAS and access-nodes and maintain handshakes, are sent by the BRAS to the access-node after the TCP connection is established. GSMP messages other than adjacency protocol messages may be sent only after the adjacency protocol has achieved synchronization. In the case of ATM access, a separate PVC (control channel) capable of transporting IP would be configured between BRAS and the DSLAM for layer2 protocol messages. 5.2 GSMP connection keep-alive GSMP defines an adjacency protocol. The adjacency protocol is used to synchronize states across the link, to negotiate which version of the GSMP protocol to use, to discover the identity of the entity at the other end of a link, and to detect when it changes. GSMP is a hard state protocol. It is therefore important to detect loss of contact between switch and controller, and to detect any change of identity of switch or controller. No GSMP messages other than those of the adjacency protocol may be sent across the link until the adjacency protocol has achieved synchronization. There are no changes to the base GSMP adjacency protocol for implementing layer2 control. Wadhwa et.al Expires December 2, 2005 [Page 13] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 The BRAS will set the M-flag in the SYN message (signifying it is the master). Once the adjacency is established, periodic adjacency messages (type ACK) are exchanged. The default ACK interval as advertised in the adjacency messages is 10 sec for layer2 control protocol. It SHOULD be configurable and is an implementation choice. 5.3 Capability negotiation The GSMP adjacency message is extended to carry technology specific "Capability TLVs". If any capability in the received adjacency message is not supported by the receiving device, it will turn off the capability locally and will trigger an updated adjacency message with the capability turned off to match the sender's capability. The adjacency will not come up unless the capabilities advertised by the controller and the controlled device match. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Timer |M| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Name | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Receiver Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType | PFlag | Sender Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Receiver Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tech Type | # of TLVs | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Capability TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of capability TLV is: Wadhwa et.al Expires December 2, 2005 [Page 14] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capability Type | Capability Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ ~ Capability Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Tech Type field type indicates the technology to which the capability extension applies. For layer2 control in case of DSL networks, new type "DSL" is proposed. The value for this field is TBD. Capability length is the number of actual bytes contained in the value portion of the TLV. The TLV is padded to a 4-octet alignment. Therefore, a TLV with no data will contain a zero in the length field (if capability data is three octets, the length field will contain a three, but the size of the actual TLV is eight octets). Capability data field can be empty if the capability is just a boolean. In case the capability is a boolean, it is inferred from the presence of the TLV (with no data). Capability data provides the flexibility to advertise more than mere presence or absence of a capability. Capability types can be registered with IANA. For now the types are TBD. Following capabilities are defined for layer2 control protocol as applied to DSL access: 1. Capability Type : Dynamic-Topology-Discovery Length (in bytes) : 0 Capability Data : NULL 2. Capability Type : Line-Configuration-Reporting Length (in bytes) : 0 Capability Data : NULL Wadhwa et.al Expires December 2, 2005 [Page 15] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 3. Capability Type : Transactional-Multicast (controller i.e. BRAS terminates IGMP messages from subscribers, and via l2 control protocol, signals state to the access-nodes (e.g. DSLAMs) to enable layer2 replication of multicast streams. In ATM access network this implies that BRAS instructs the access-node to setup a P2MP cross-connect. The details of this will be covered in a separate ID [6]. Length (in bytes) : 0 Capability Data : NULL 5.4 GSMP Message Extensions for L2 control 5.4.1 Topology Discovery The GSMP Event message with PORT UP message type (80) is used for conveying DSL line attributes to the BRAS. The Port and Label fields are set to 0. The Tech Type field is extended with new type "DSL". The value for this field is TBD. Wadhwa et.al Expires December 2, 2005 [Page 16] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub | Message Type | Result| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Session Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|S|x|x| | +-+-+-+-+ Label | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Extension Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the "Extension Value" field for Tech Type “DSL” is as follows : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # of TLVs | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ ~ TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The “Extension Value” contains one or more TLVs to identify a DSL line and define it’s characteristics. A TLV can consist of multiple sub-TLVs. First 2 byte of the “Extension Value” contains the number of TLVs that follow. Wadhwa et.al Expires December 2, 2005 [Page 17] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 General format of a TLV is : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ ~ Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value field in each TLV is padded to a 4-octet alignment. The Length field in each TLV contains the actual number of bytes in the TLV (not including the padding if present). If a TLV is not understood by the BRAS, it is silently ignored. Currently defined types start from 0x01. Following TLVs are currently defined: 1. Type (Access-Loop-Circuit-ID = 0x01): This is a mandatory TLV and contains an identifier of the subscriber’s connection to the access node (i.e. “local loop”). The “local loop” can be ATM based or Ethernet based. The “Access Loop Circuit ID” has local significance at the access node. The exact usage on the BRAS is beyond the scope of this document. It is desirable that the format used for “local loop” identification in GSMP messages is similar to what is used by the access nodes in subscriber signaling messages when the access nodes act as “signaling relay agents” as outlined in [7] and [8]. Length : (upto 63 bytes) Value : ASCII string. For an ATM based local loop the string consists of slot/port and VPI/VCI information corresponding to the subscriber’s DSL connection. Typical format for the string inserted by the access node is: ‘‘[Access-Node-Identifier] atm slot/port:vpi.vci ’’ The Access-Node-Identifier uniquely identifies the access node in the access network. The slot/port and VPI/VCI uniquely identifies the DSL line on the access node. Also, there is one to one correspondence between DSL line and the VC between the access node and the BRAS. Wadhwa et.al Expires December 2, 2005 [Page 18] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 For local loop which is Ethernet based (and tagged), the string consists of slot/port and VLAN tag corresponding to the subscriber. Typical format for the string is: "[Access-Node-Identifier] eth slot/port[:vlan-tag]" 2. Type (Access-Aggregation-Circuit-ID-Binary = 0x02) Length : (8 bytes) Value : two 32 bit integers. For ethernet access aggregation, where a per-subscriber (stacked) VLAN can be applied (1:1 model defined in [8]), the VLAN stack provides a convenient way to uniquely identify the DSL line. The outer VLAN is equivalent to virtual path between a DSLAM and the BRAS and inner VLAN is equivalent to a virtual circuit on a per DSL line basis. In this scenario, any subscriber data received by the access node and transmitted out the uplink to the aggregation network will be tagged with the VLAN stack assigned by the access node This TLV can carry the VLAN tags assigned by the access node in the GSMP messages. The VLAN tags can uniquely identify the DSL line being referred to in the GSMP messages, assuming the VLAN tags are not in any way translated in the aggregation network and are unique across physical ports. Also, in case of an ATM aggregation network, where the DSLAM is directly connected to the BRAS (without an intermediate ATM switch), the two values can contain VPI and VCI on the DSLAM uplink (and can uniquely identify the DSL line on the DSLAM). 3. Type (Access-Aggregation-Circuit-ID-ASCII = 0x03) Length : (upto 63 bytes) Value : ASCII string. This field contains information pertaining to an uplink on the access node. For Ethernet access aggregation, assuming the access node assigns VLAN tags (1:1 model), typical format for the string is: Wadhwa et.al Expires December 2, 2005 [Page 19] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 ‘‘ [Access-Node-Identifier] eth slot/port [:inner-vlan-tag][:outer-vlan-tag] ’’ The slot/port corresponds to the ethernet uplink on the access node towards the BRAS. For an ATM aggregation network, typical format for the string is: ‘‘ [Access-Node-Identifier] atm slot/port:vpi.vci ’’ This TLVs allows the BRAS to associate the information contained in the GSMP messages to the DSL line on the access node. If the access node inserts this string in the GSMP messages, when referring to local loop characteristics (e.g. DSL line in case of a DSLAM), then it should be able to map the information contained in the string uniquely to the local loop (e.g. DSL line). On the BRAS, the information contained in this string can be used to derive an “aggregation network” facing construct (e.g. an IP interface) corresponding to the local loop (e.g. DSL line). The association could be based on “local configuration” on the BRAS. The access node can also convey to the BRAS, the characteristics (e.g. bandwidth) of the uplink on the access node. This TLV then serves the purpose of uniquely identifying the uplink whose characteristics are being defined. A separate set of sub-TLVs will be defined for the uplink characteristics (TBD). 4. Type (DSL Line Attributes = 0x04): Length : variable (up to 1024 bytes) Value : This consists of one or more Sub-TLVs corresponding to DSL line attributes. The general format of the sub-TLVs is identical to the general TLV format. The value field in each sub-TLV is padded to a 4-octet alignment. The Length field in each sub-TLV contains the actual number of bytes in the TLV (not including the padding if present). Current defined sub-TLV types are start from 0x81. Following sub-TLVs are currently defined : . Type (DSL-Type = 0x90) : Defines the type of transmission system in use. This is a mandatory TLV. Wadhwa et.al Expires December 2, 2005 [Page 20] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 Length : (4 bytes) Value : (Transmission system : ADSL1, ADSL2, ADSL2+, VDSL1,VDSL2, SDSL) . Type (Actual-Data-Rate-Upstream = 0x81) : Actual data rate upstream of a synchronized DSL line. This is a mandatory TLV. Length : (4 bytes) Value : (Rate in Kb/sec) . Type (Actual-Data-Rate-Downstream = 0x82) : Actual data rate downstream of a synchronized DSL line. This is a mandatory TLV. Length : (4 bytes) Value : (Rate in Kb/sec) . Type (Minimum-Data-Rate-Upstream = 0x83) : Minimum data rate desired by the operator. This is optional. Length : (4 bytes) Value : (Rate in Kb/sec) . Type (Minimum-Data-Rate-Downstream = 0x84) : Minimum data rate desired by the operator. This is optional. Length : (4 bytes) Value : (Rate in Kb/sec) . Type (Attainable-Data-Rate-Upstream = 0x85) : Maximum upstream rate that can be attained on the DSL line. This is an optional TLV. Length : (4 bytes) Value : (Rate in Kb/sec) . Type (Attainable-Data-Rate-Downstream = 0x86) : Maximum downstream rate that can be attained on the DSL line. This is an optional TLV. Length : (4 bytes) Value : (Rate in Kb/sec) Wadhwa et.al Expires December 2, 2005 [Page 21] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 . Type (Maximum-Data-Rate-Upstream = 0x87) : Maximum data rate desired by the operator. This is optional. Length : (4 bytes) Value : (Rate in Kb/sec) . Type (Maximum-Data-Rate-Downstream = 0x88) : Maximum data rate desired by the operator. This is optional. Length : (4 bytes) Value : (Rate in Kb/sec) . Type (Minimum-Low-Power-Data-Rate-Upstream = 0x89) : Minimum data rate desired by the operator in low power state. This is optional. Length : (4 bytes) Value : (Rate in Kb/sec) . Type (Minimum-Low-Power-Data-Rate-Downstream = 0x8A) : Minimum data rate desired by the operator in low power state. This is optional. Length : (4 bytes) Value : (Rate in Kb/sec) . Type (Maximum-Interleaving-Delay-Upstream = 0x8B) : maximum one way interleaving delay. This is optional. Length : (4 bytes) Value : (Time in msec) . Type (Actual-Interleaving-Delay-Upstream = 0x8C) : Value corresponding to the interleaver setting. This is optional. Length : (4 bytes) Value : (Time in msec) Wadhwa et.al Expires December 2, 2005 [Page 22] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 . Type (Maximum-Interleaving-Delay-Downstream = 0x8D) : maximum one way interleaving delay. This is optional. Length : (4 bytes) Value : (Time in msec) . Type (Actual-Interleaving-Delay-Downstream = 0x8E) : Value corresponding to the interleaver setting. This is optional. Length : (4 bytes) Value : (Time in msec) 5.4.2 Line Configuration The BRAS uses extension block in the Port Management messages to convey service attributes of the DSL lines to the DSLAM. TLVs are defined for DSL line identification and service data for the DSL lines. Port number is set to 0 in the message. A new action type "Configure Connection Service Data" (value 0x8 or TBD) is defined. The "Function" field is set to the action type. This action type indicates to the device being controlled (access-node i.e. DSLAM) to apply service configuration data contained in the extension value (TLVs), to the DSL line (identified by one of the TLVs in the extension value). The Tech Type field is extended with new type "DSL". The value for this field is TBD. Wadhwa et.al Expires December 2, 2005 [Page 23] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub | Message Type | Result| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Session Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|x|x|x|x|x|x|x| Duration | Function | X-Function | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Flags | Flow Control Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Extension Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the "Extension Value" field is as follows : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # of TLVs | Unused (in bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ ~ TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The “Extension Value” field contains one or more TLVs containing DSL line identifier and desired service attributes of the the DSL line. First 2 byte of the “Extension Value” contains the number of TLVs that follow. Wadhwa et.al Expires December 2, 2005 [Page 24] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 General format of a TLV is : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ ~ Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value field is padded to a 4-octet alignment. The Length field in each TLV contains the actual number of bytes in the TLV (not including the padding if present). If a TLV is not understood by the BRAS, it is silently ignored. Depending upon the deployment scenario, the BRAS may specify “Access Loop Circuit-ID” or the “Access Aggregation Circuit-ID) as defined in section 5.4.1. Following TLVs can appear in this message: o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1 o Type (Access-Aggregation-Circuit-ID-Binary = 0x02): defined in section 5.4.1. o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03) : defined in section 5.4.1. o Type (Service-Profile-Name = 0x05) : Reference to a pre-configured profile on the DSLAM that contains service specific data for the subscriber. Length : (upto 64 bytes) Value : ASCII string containing the profile name (BRAS learns from a policy server after a subscriber is authorized). In future, more TLVs MAY be defined for individual service attributes of a DSL line (e.g. rates, interleaving delay, multicast channel entitlement access-list etc). 5.5 ATM-specific considerations The topology discovery and line configuration involve the DSL line attributes. For ATM based access networks, the DSL line on the DSLAM is identified by the port and PVP/PVC corresponding to the Wadhwa et.al Expires December 2, 2005 [Page 25] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 subscriber. The DSLAMs are connected to the BRAS via an ATM access aggregation network. Since, the DSLAM (access-node) is not directly connected to the BRAS, the BRAS needs a mechanism to learn the DSL line identifier (more generally referred to as "Access Loop Circuit- ID") corresponding to a subscriber. The "Access loop circuit-ID" has no local significance on the BRAS. The GSMP messages for topology discovery and line configuration carry opaque "Access loop Circuit- ID" which has only local significance on the DSLAMs. The access loop circuit identifier can be carried as an ASCII string in the GSMP messages. This allows layer2 control protocol to be decoupled from the specifics of the underlying access technology being controlled. On the other hand, this requires a BRAS mechanism by which such identifier can be correlated to the context of an “aggregation network” facing IP interface (corresponding to the subscriber) on the BRAS. This would typically require local configuration of such IP interfaces, or of the underlying ATM interfaces. 5.6 Ethernet-specific considerations One possible way of approaching the use of Ethernet technology in the access aggregation network is to recreate the equivalent of Virtual Paths (VPs) and Virtual Circuits (VCs) by using stacked Virtual LAN tags. As an example, one could use an “outer” VLAN to create a form of “virtual path” between a given DSLAM and a given BRAS. And then use “inner” VLAN tags to create a form of “virtual circuit” on a per DSL line basis. In this case, VLAN tags conveyed in topology discovery and line configuration messages will allow to uniquely identify the DSL line in a straightforward manner, assuming the VLAN tags are not translated in some way by the aggregation network, and are unique across physical ports. However, some carriers do not wish to use this “connection oriented” approach. Therefore, an alternative model is to bridge sessions from multiple subscribers behind a DSLAM to a single VLAN in the aggregation network. This is the N:1 model. In this model, or in the case where user traffic is sent untagged, the access node needs to insert the exact identity of the DSL line in the topology discovery and line configuration messages, and then have a mechanism by which this can be correlated to the context of an “aggregation network” facing IP interface (for the subscriber) on the BRAS. This can either be based on local configuration on the BRAS, or on the fact that such DSLAM (access node) typically inserts the “Access Loop Circuit ID” in subscriber Wadhwa et.al Expires December 2, 2005 [Page 26] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 signaling messages relayed to the BRAS (i.e. DHCP or PPPoE discovery messages). Section 5.4.1 defines “Access Loop Circuit ID”. 5.7 Graceful restart considerations (TBD) 6 IANA Considerations New Tech-Type, capability types, sub-TLV types related to topology discovery and line configuration will need to be reserved. 7 Security Considerations The BRAS and DSLAMs are implicitly in a trusted domain, so security for L2-Control protocol is not a strong requirement. However if needed security can be provided using IP security as indicated in [RFC3293]. 8 References [1] DSLForum TR-059, DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services, Tom Anschutz (BellSouth Telecommunications), 09/2003. [2] DSLForum TR-058, Multi-Service Architecture & Framework Requirements, Mark Elias (SBC) and Sven Ooghe (Alcatel), 09/2003. [3] DSLForum TR-092, Broadband Remote access server requirements document. [4] Doria, A., "GSMPv3 Base Specification", draft-ietf-gsmp-v3- base-spec-06, Nov 2004. [5] Worster, T., Doria, A. and J. Buerkle, "General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)", RFC 3293, June 2002. [6] GSMP extensions for layer2 control - Transactional Multicast, draft-moisand-gsmp-l2control-multicast-00 (work in progress). Wadhwa et.al Expires December 2, 2005 [Page 27] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 [7] “DHCP Relay Agent Information Option”, RFC 3046, January 2001. [8] Architecture & Transport: Migration to Ethernet Based DSL Aggregation, DSL Forum WT-101, Cohen et al. Author's Addresses Jerome Moisand Juniper Networks 10 Technology Park Drive Westford, MA 01886 Email: jmoisand@juniper.net Sanjay Wadhwa Juniper Networks 10 Technology Park Drive Westford, MA 01886 Email: swadhwa@juniper.net Swami Subramanian Juniper Networks 10 Technology Park Drive Westford, MA 01886 Email: ssubramanian@juniper.net 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 Wadhwa et.al Expires December 2, 2005 [Page 28] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-00 August 2005 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 (2005). 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 We would like to thank Swami Subramanian of Juniper Networks for reviewing and commenting on the draft. Wadhwa et.al Expires December 2, 2005 [Page 29]