280 likes | 292 Views
This document discusses the Layer2 Control Protocol (L2CP) designed for controlling operations in access networks, emphasizing flexibility, scalability, and efficiency. It outlines the protocol's applicability, features, and use cases.
E N D
GSMPv3 applicability to L2CPdraft-wadhwa-gsmp-l2control-configuration-00.txtL2CP BOFIETF-65 Sanjay Wadhwa Juniper Networks
Agenda • Layer2 Control in Access Networks (L2CP) • GSMPv3 applicability to L2CP • GSMPv3 extensions for L2CP • Adjacency Protocol • Access-Line discovery • Line Configuration • Remote connectivity check • “Transactional” Multicast • Current Status IETF 65 (L2C BOF)
L2CP : Layer2 Control Protocol in DSL Access Networks • BNG (Broadband Network Gateway) • Aggregation point for subscriber traffic. • Serves as injection point for policy and IP QOS management in access/regional network. • Acess-Node • Terminates the “local-loop”. • First point in the network where traffic is aggregated from multiple “local-loops” on to a single network (e.g. DSLAM in DSL access networks). IETF 65 (L2C BOF)
Video Head End or ASP ISP (Internet) Broadband Access Aggregation Network Customer Premises Network Access Aggregation Network Regional Broadband Network RG BNG DSLAM (Access-Node) ASP (e.g. IP Telephony) Aggregation Network IP Backbone RG L2CP IETF 65 (L2C BOF)
L2CP: Layer2 Control in Access Networks • Control Plane required between BNG and Access-node for dynamic “QOS-related”, “service-related” and “subscriber-related” operations. • Dynamic control protocol eliminates dependency on integration with a complex OSS system spanning multiple entities. IETF 65 (L2C BOF)
L2C: Layer2 Control in Access Networks • Desired control plane attributes: • Simple • Ease of implementation • Time to market • Light-weight • Allow implementation on AN with limited control plane resources (CPU/memory) • Extensible • Possible to extend the protocol for use-cases relevant to access technologies other than DSL (e.g PON). • Supports addition of new capabilities in a downward compatible manner. IETF 65 (L2C BOF)
L2C: Layer2 Control in Access Networks • Flexible • Independent of underlying access/aggregation network (e.g. ATM or Ethernet). • Supports transactional exchange • Request/response model for BNG to communicate control decisions or request information from AN. • Supports “asynchronous” notifications from AN to BNG. IETF 65 (L2C BOF)
L2C: Layer2 Control in Access Networks • Minimize configuration overhead and maximize automation of operation. • OPEX reduction • Supports configurable keep-alive • Detection for loss of connectivity and failure of peer node. • Support efficient resynchronization after loss of peering. • Supports graceful shutdown notification. IETF 65 (L2C BOF)
L2C: Layer2 Control in Access Networks • Scalable • Number of adjacencies • Number of transactions • Does not require any soft state. • Supports Incremental update of information. • Ease of supporting non-disruptive “on demand” state refresh capability. • Ease of supporting Graceful Restart and High availability. IETF 65 (L2C BOF)
GSMPv3 applicability to L2C • Leverage subset of GSMPv3 as the base control protocol to build upon. • Subset of GSMPv3 relevant to L2C identified in draft-wadhwa-gsmp-l2control-configuration-00.txt. • Contains DSL specific modifications and extensions to GSMPv3 for few currently envisaged use-cases of L2C. • Based on draft-ietf-gsmp-v3-base-spec-07.txt IETF 65 (L2C BOF)
GSMPv3 applicability to L2C • Master (Controller) - BNG (Broadband Network Gateway) • Slave (Switch) - Access Node (e.g. DSLAM in DSL access) • GSMP over TCP encaps • Separate “logical connection” for L2C. IETF 65 (L2C BOF)
GSMPv3 applicability to L2C • GSMP Connection Establishment • Access-node (slave) initiates TCP connection • Ease of provisioning on BNG • Divergence from base GSMP specification IETF 65 (L2C BOF)
Adjacency Protocol : Extension • Base GSMP adjacency protocol is extended: • Adjacency messages extended to carry Capability TLVs. • Negotiation procedure for “Least Common Denominator” capability set defined. • Capability mis-match prevents adjacency to be formed. • Capabilities defined for current use-cases. • Configurable adjacency keepalive (ACK) interval. IETF 65 (L2C BOF)
Use Case 1: Access Line Discovery • Access-node asynchronously informs BNG of access-line state and attributes (e.g. sync rate) when line comes up. • BNG can adjust QOS for the local-loop based on the sync rate (aka “remote link scheduling”). • BNG can inform the access-line attributes to a policy server. • Embedded “business logic” in the policy server can factor in the access-line attributes. • Policy server can then trigger the BNG to turn on/off services or modify service attributes for the subscriber on the local loop. IETF 65 (L2C BOF)
Use Case 1: Access Line Discovery • Change in access-line attributes also reported to the BNG. • Access-line reporting uses GSMP “Port-Up” and “Port-Down” EVENT messages. • TLVs defined for “access-line identification” and “access-line attributes”. • TLVs are carried in “technology specific extension block” of the EVENT message. • “Technology Type” field is extended with a new value for “DSL”. IETF 65 (L2C BOF)
Video Head End or ASP ISP (Internet) Internet Port RG IPTV Port 8- Business logic Access-line Discovery Radius 7-Sync Rate to radius in access-request 4-PORT_UP MESSAGE ACI : [TCOM-Dslam-1]eth 207/1:350 Line Attributes : Downstream = B/W 768 Upstream = B/W 300 Local Loop Type = ATM 9-Service VSAs • Ensures no congestion in the access network 5-Access Loop Parameters Stored 3-RG Turned On, Synchronized with DSLAM BNG 1-L2CP Session Established DSLAM ASP (e.g. IP Telephony) 2-Access-Line Discovery Capability Advertised IP Backbone 6-Set Shaping Rate, Adjust Shaping Mode 2-Subscriber logs in (PPP/DHCP session) IETF 65 (L2C BOF)
Video Head End or ASP ISP (Internet) Internet Port RG IPTV Port 8- Business logic Access-line Attributes Update Radius 7-Sync Rate to radius in access-request 4-PORT_UP MESSAGE (Updated Line Parameters) ACI : [xyz-Dslam-1]eth 207/1:350 Line Attributes : Downstream = B/W 512K Upstream = B/W 300 Local Loop Type = ATM 9-Service VSAs • QOS and Service control updated 5-Access Loop Parameters Updated 1-DSL LINE RESYNCH BNG DSLAM ASP (e.g. IP Telephony) IP Backbone 6-Set Shaping Rate, Adjust Shaping Mode IETF 65 (L2C BOF)
Access Line Discovery • Best-practice recommendations: • Desirable to dampen Access-line state changes by the Access-Node. • Desirable to use use “BULK” transaction message for access-line reporting on startup. IETF 65 (L2C BOF)
Use Case 2: Line Configuration • BSR “managed” access and QOS control enforced by the access-node. • Provides for centralized “service management”. • BSR can download service profiles/parameters to the access-node (e.g. “IGMP Filter Lists”) via L2C. • “Line Config” uses GSMP “Port Management” message to convey “service attributes” from the BNG to the Access-node. • “Function” field carried in the message has been extended with a new value to support “line configuration”. • TLVs defined for “access-line identification” and “service attributes”. • TLVs are carried in “technology extension block” of the PORT_MANAGEMENT message. • “Technology type” is extended with a new value for “DSL” IETF 65 (L2C BOF)
Video Head End or ASP ISP (Internet) Enterprise VPNs Internet Port RG IPTV Port 8- Business logic Line Configuration Radius 7-Sync Rate to radius in access-request 4- EVENT (PORT_UP) MESSAGE ACI : [TCOM-Dslam-1]eth 207/1:350 Line Attributes : Downstream = B/W 768 Upstream = B/W 300 Local Loop Type = ATM 9-Service VSAs 5-Access Loop Parameters Stored 3-RG Turned On, Synchronized with DSLAM BNG 1-L2C Session Established DSLAM ASP (e.g. IP Telephony) 2-Access-Line Discovery & Line Config Capability Advertised IP Backbone 2-Subscriber logs in (PPP/DHCP session) 6-Set Shaping Rate, Adjust Shaping Mode 10- PORT_MANAGEMENT MESSAGE ACI : [TCOM-DSLAM-1] eth 207/1:350 Service-Profile : Gold IGMP-Profile : Premium-Package IETF 65 (L2C BOF)
Video Head End or ASP ISP (Internet) Enterprise VPNs Internet Port RG IPTV Port 2- Business logic Line Configuration Update Web Portal/OSS etc Radius/AAA Policy 3-Change of Authorization 1-Service on Demand BNG 1-Subscriber logs in (PPP/DHCP session) DSLAM ASP (e.g. IP Telephony) IP Backbone 10- PORT_MANAGEMENT MESSAGE ACI : [TCOM-DSLAM-1] eth 207/1:350 Service-Profile : Gold IGMP-Profile : Premium-Package IETF 65 (L2C BOF)
Use Case 3: Remote Connectivity Check • BNG triggered “local loop” test capability. • Provides fault detection and to some extent fault isolation. • L2 Network Independent • Verify the integrity of a local loop • Request AN Initiate Loop-specific LB Procedure • LB Results returned to BNG via L2C • AN can trigger: • F5 loopback cells for ATM based local loop • 8023.ah procedures for EFM. Aggregation Network L2C: Port Management Remote LB for ACI L2-specific loop-back procedure L2C: Port Management LB Report for ACI – Success/Fail Code: 0x500 : Specified access line does not exist. 0x501 : Loopback test timed out. 0x502 : Reserved 0x503 : DSL line status showtime. 0x504 : DSL line status idle. 0x505 : DSL line integrity silent. 0x506 : DSL line status training 0x507 : DSL line integrity error 0x508 : DSLAM resource not available 0x509 : invalid test parameters IETF 65 (L2C BOF)
Remote Connectivity Check • PORT_MANAGEMENT message is used for OAM request and response. • “Function” field in the message extended with a new “remote loopback” value. • PORT_MANAGEMENT message carrying the loopback test response has a valid “result” field (Success/Failure) • “Code” field in PORT_MANAGEMENT message extended to carry detailed OAM loopback test response. IETF 65 (L2C BOF)
Use Case 4 : Transactional Multicast • Typically, BNG terminates user requests for receiving multicast channels via IGMP. • BNG performs “authorization” , “access-control” (checks subscription rights for the subscriber) and does admission control. • Ideal for BNG to send a single copy of “multicast stream” to a given access-node (as opposed to a separate copy for each subscriber behind the access-node). • BNG can set “replication state” in the access node using L2C (e.g. P2MP PVC cross-connect OR mapping of “multicast MAC” to access-lines) • Access node can replicate based on native L2 mechanisms (e.g. ATM p2mp cell replication or ethernet data-link bridging). • GSMP extensions for this use-case : TBD. IETF 65 (L2C BOF)
Current Status • Some work to define L2C use-cases is happening in DSL forum (Working Text 147) • Desirable to undertake framework/requirement, and protocol specification work for L2C in IETF. • L2C framework/requirements and GSMPv3 extensions for L2C are defined in draft-wadhwa-gsmp-l2control-configuration-00.txt. • Framework/requirements also defined in a later ID draft-ooghe-l2c-framework-00.txt. The two drafts should be combined to yield a single requirements draft. • Initial inter-operable implementations from different vendors (3 BNG and 4 DSLAM) exist based on draft-wadhwa-gsmp-l2control-configuration-00.txt • Field trials of these implementations underway. IETF 65 (L2C BOF)
Potential Protocol Work • Mechanism for “Graceful Restart”. • Mechanisms/Extensions to scale to a large number of L2C adjacencies. • Support for “subtended DSL topologies” (large number of remote Access-nodes controlled by a central BNG). • Mechanism on BNG for non-disruptive, “on-demand” retrieval of all state on the Access node. • Definition of MIBs. • Support for redundant controllers (BNGs) for a single AN (or a single partition on an AN) • Applicability to other broadband access technologies (e.g. PON, WIMAX etc). • If needed, support for appropriate security mechanisms (to ensure authentication of message initiator and integrity of messages). IETF 65 (L2C BOF)
Recommendations • An IETF WG be formed to undetake L2C framework, requirements and protocol specification work. • “GSMPv3 extensions for L2C” draft be considered as a WG item. IETF 65 (L2C BOF)
Thank You IETF 65 (L2C BOF)