MPLS Working Group Dave Allan, Ed. Internet Draft Ericsson Intended status: Standards Track Expires: August 2012 February 2012 Requirements and Framework for Unified MPLS Sub-Network Interconnection draft-allan-mpls-unified-ic-req-frmwk-00 Abstract The definition of a transport profile for MPLS means that MPLS network architectures will emerge that combines both managed and control plane driven MPLS sub-networks and requires interconnection of same to achieve a unified MPLS architecture. This document generalizes the problem of sub-network interconnect, discusses issues in general and suggests ways forward. Requirements Language 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 [1]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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. Allan et al., Expires August, 2012 [Page 1] Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-00 February 2012 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire in August 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................4 2.1. Terminology..................................................4 2.2. Acronyms.....................................................4 3. Sub-Network Interconnect Scenarios.............................4 4. Sub-Network Interconnect Mechanisms............................5 4.1. Border Node..................................................5 4.2. Border Link..................................................5 5. Sub-network types..............................................5 5.1. Infrastructure sub-network types.............................5 5.2. Service Sub-network types....................................6 6. Issues & Requirements..........................................6 6.1. Alignment of connectivity models..Error! Bookmark not defined. 6.2. Alignment of OAM functionality...............................6 6.3. OAM identifier mismatches....................................7 6.4. Protection Mechanisms........................................7 6.5. Label space management.......................................8 6.6. Path maintenance and re-sizing...............................8 6.7. Sub-network migration........................................8 6.8. (Non)Interworking of DP and CP notifications.................8 7. Operational Decoupling.........................................9 8. Acknowledgments................................................9 9. IANA Considerations............................................9 10. Security Considerations.......................................9 11. References...................................................10 11.1. Informative References.....................................10 Allan et al., Expires August, 2012 [Page 2] Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-00 February 2012 1. Introduction Networks that provide an end-to-end service infrastructure are typically deployed as multiple domains or sub-networks in order to scale. These different domains may be operated by different technologies using different control plane technology (e.g. management driven control plane (centralized) or distributed control plane). Within the MPLS control plane there exist a number of functional behaviors that are typically associated with a single control protocol and function autonomously from the other control protocols. That is to say when a labeled layer and associated control protocol is overlaid on another, there is frequently no operational coupling between them. When two control protocols are operated side by side the same is true (e.g. ships in the night). An example of the former would be pseudo wires over a PSN. An example of the latter would be L2 and L3 virtual private networks (VPNs) sharing a common packet switched network (PSN). The introduction of transport functions to MPLS and the intent to deploy, merge or otherwise combine networks that will concatenate sub-networks that have different operational characteristics and/or control planes (including management) introduces the requirement to integrate operations across multiple sub-networks. This frequently is manifested in requirements on nodes at sub-network boundaries and/or alignment of identifiers in order to construct a unified end-to-end MPLS based service plane. By having a unified MPLS based service plane, a network operator is able to provide services across different MPLS domains instrumented with common management and control functionality in order to provide scalable service offerings on a common MPLS technology base. This document is a framework that postulates models and functional requirements for sub-network interconnect to achieve a unified end to end MPLS based service plane or "Unified MPLS". Allan et al., Expires August, 2012 [Page 3] Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-00 February 2012 2. Conventions used in this document 2.1. Terminology Binding: Is the mechanism for association and interconnection of label switched path (LSP) or pseudo wire (PW) segments that exist in different sub-networks. Section: As per RFC 5960[17]. Segment: A part of a PW or LSP that has one or more contiguous sections in a common sub-network. This usage is as per RFC 6372[18]. Sub-network: A portion of a larger MPLS network that is operated by a single system and whose boundaries are set by the scope of the system. The system may be a control plane or management system. Similarly it could be a sub-layer stacked on another sub-network. 2.2. Acronyms LIB - label information base LSP - label switched path MEG - Maintenance Entity Group MEP - Maintenance Entity Group End Point MIP - Maintenance Entity Group Intermediate Point PSN - packet switched network PW - pseudo wire SPME - Sub-path Maintenance Entity 3. Sub-Network Interconnect Scenarios The combination of MPLS label swapping and label stacking makes it possible to consider a number of atomic interconnect scenarios, briefly summarized here: Peer Model - is the scenario when an LSP or PW has segments in different sub-networks. Segmentation Model - is the scenario when a client LSP or PW with common establishment and maintenance procedures has sections in separate sub-networks. This model can recurse arbitrarily. Allan et al., Expires August, 2012 [Page 4] Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-00 February 2012 Overlay Model - is the simplest case of the segmentation model in which a section of an LSP or PW is a distinct sub-network. Termination Model - is the scenario where a non-MPLS or PW transfer function separates the sub-networks. The termination model logically isolates the sub-networks and is included simply for completeness. 4. Sub-Network Interconnect Mechanisms There are two interconnect mechanisms considered. The first (Border node) postulates a node that spans two sub-networks and both likely operated by a single provider. The second (Border link) postulates a link connecting sub-networks of two distinct organizations within a provider or two distinct providers. 4.1. Border Node A border node is one that implements, interconnects and interworks LSPs or PWs with segments or sections in different sub-networks. The interworking function at the border node will either terminate, swap or encapsulate labels. 4.2. Border Link A border link is the case whereby two border nodes are connected back to back in a sub-network that consists of a single link. 5. Sub-network types In the current MPLS architecture the following sub-network types exist: 5.1. Infrastructure sub-network types MPLS-TD: Topology driven MPLS. LSP setup is via the LDP protocol [6] with path routing determined by the IGP. ECMP, merging and PHP are are included in the set of possible dataplane behaviors. P2mp LSPs are supported by mLDP [7]. MPLS-TE: LSP setup is via the RSVP-TE protocol[8] with path routing determined by a TE enabled IGP (e.g. OSPF-TE) according to bandwidth and QoS constraints. PHP is included in the set of dataplane behaviors. Bandwidth allocation, class of service or priotity(PHB) are typically part of traffic handling. Managed MPLS-TP: LSP setup is via management action. LSPs are purely connection oriented p2p or p2mp. Allan et al., Expires August, 2012 [Page 5] Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-00 February 2012 Signalled MPLS-TP: LSP setup is via RSVP-TE GMPLS[9]. LSPs are purely connection oriented p2p or p2mp. 5.2. Service Sub-network types L3VPN: VPN setup is via the BGP protocol as per RFC 4364[10]. Note that this can be an IP-VPN (via IGP peering with the VRF) or an MPLS- VPN (via a combination of IGP and MPLS CP peering with the VRF). L2VPN: VPN setup is via the PW Control Protocol per RFC 4447 (LDP in targeted mode) or BGP protocols. A broadcast domain is emulated which will have the effect of limiting sub-network interconnect to a single point to avoid loops. VPWS: VPWS setup is via the PW Control Protocol per rfc 4447 (LDP in targeted mode). 6. Issues & Requirements In theory, any ingress label can be mapped to one or more egress labels or label stack permutations via the ILM to NHLFE mapping defined in RFC 3031[2]. Further one carrier"s infrastructure layer may be a client of another carrier"s infrastructure. More considerations need to come into play in order to produce a tractable set of sub-network interworking scenarios. The following is a partial list of some of the issues to be considered and/or addressed: 6.1. Alignment of OAM functionality Not all OAM encapsulations guarantee fate sharing with the LSP of interest across all of the sub-network types in MPLS. This not only means that failures may not be detected or detected in a timely manner, it also means that "false positives" are a possibility as failures may occur on the path taken by the OAM PDUs. Any OAM encapsulation using a reserved label, e.g. the GAL[12], or Router Alert as used by VCCV type 2[13], or without a PW control word will not have predictable control over fate sharing with normal payload for any LSP or PW that has a section that transits a MPLS-TD subnetwork that implements ECMP[11]. A separate issue is interconnecting subnetworks where the LSPs have a different cardinality of end points (e.g. concatenating mp2p to p2p), implying a different number of maintenance entities than would be suggested by an implementation dimensioned to a single subnetwork"s characteristics. Allan et al., Expires August, 2012 [Page 6] Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-00 February 2012 6.2. OAM identifier mismatches MEG, MEP, MIP and nodal addressing will not pose identifier mismatch problems. Where such problems will arise is in the use of RFC 4379 LSP Ping [3]. This is because LSP-PING uses identifiers associated with a specific sub-network type in the FEC stack as part of the processing to detect inconsistencies between the control plane and the data plane. [Issue: The on demand cv draft provides for the Static LSP and Static PW TLVs for the FEC stack which allows intermediate nodes to validate the FEC stack against the MEG ID for the local MIP. The applicability for this should be generalized such that it can be used end to end across domains. This will also raise the problem of disseminating MEG information to non-transport subnetworks as not all defined MPLS sub- network types use the current fields in the IP based LSP MEG ID] 6.3. OAM encapsulation The MPLS architecture permits multiple OAM encapsulations that may or may nor have an IP header. Any interconnect mechanism needs to be able to align not only capability but encapsulations end to end. 6.4. Protection Mechanisms An MPLS LSP or PW sub-network may be made resilient by any number of mechanisms. There is also three scenarios of note, end to end protection, end to end restoration and sub-network protection. End to end protection offers minimal complications in sub-network interconnect as the interworking functions is common to that of the unprotected case, that is to say transit nodes do not participate in protection switching. Sub-network protection is universally offered by the use of mechanisms that operate within the level such as detours [19] and may require label merging at the border node. Mechanisms that operate at nested MPLS label levels (e.g. SPMEs or FRR facility protection) have no impact on sub-network interconnect. End to end restoration is a bit more complicated as it involves coordinating dynamic action between sub-networks. It also becomes possible to consider sub-network restoration with many of the same considerations as path maintenance and re-sizing. Allan et al., Expires August, 2012 [Page 7] Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-00 February 2012 6.5. Label space management The MPLS architecture has always been based around local administration of a node"s label space. As such mechanisms to partition the label space between multiple administrative entities is not currently supported and would be difficult to retrofit. A consequence of this is that a border node is potentially required to provide labels from a common pool to both a control and management plane, e.g. a management system be required to obtain label values from the node prior to populating the LIB vs. being delegated a pool. This suggests that such a mechanism be carried forward for all managed nodes such that only a single mechanism need be implemented. However this is an implementation decision. 6.6. Path maintenance and re-sizing It must be possible to make operational modifications to a path segment in a hitless fashion. The normal procedure for MPLS-TE is known as "make before break". This gives rise to two scenarios, the first is end to end "make before break", and the other is make before break confined to a sub-network with the border node as a pinned waypoint. This means the design of the inter-sub-network binding information permit make before break modification of one segment of the LSP. 6.7. Sub-network migration The practical considerations are documented in RFC 5950[4] and by reference RFC 5493[5]. 6.8. (Non)Interworking of DP and CP notifications Within the MPLS architecture there are techniques for propagating the status of adjacent sections of either a native service or PW section in both the data plane and the control plane. One example (documenting both) is RFC 6310[14]. When concatenating subnetworks the interworking of dataplane fault notifications [15] or protection switching coordination [16] and control plane indications will not be possible. The reason is that data plane indications flow end to end on a labeled path therefore will not be visible to border nodes, a requirement to enable interworking of dataplane notifications with the control plane in any useful form. When connecting a subnetwork restricted to data plane only notifications to a subnetwork that will support either dataplane or Allan et al., Expires August, 2012 [Page 8] Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-00 February 2012 control plane notifications, the border node will be required to negotiate exclusive use of dataplane notifications in any control plane signaling during the path setup. This will have implications in both the interconnect data model, and potential enhancements to signaling. 7. Operational Decoupling The objective of any sub-network interconnect solution is to decouple the operation of the interconnected systems in order to minimize any dependencies. The sub-network interconnect must accommodate interconnecting LSPs and PWs with different establishment and persistency characteristics. This is determined by whether the LSP, PW or segment is provisioned or signaled, where from a persistency point of view, a provisioned entry is permanent and exists until removed by management action, while a signaled entity fate shares with a control plane adjacency and may come and go during the life time of the inter sub-network binding. The state present at a border node to bind the LSP or PW spanning the subnetworks together should exist independently of the characteristics of the LSPs or associated control or management planes. This also requires a level of indirection such that the management action is decoupled from the mechanics of label assignment in each sub-network and may work with sub-network resiliency mechanisms. So the state "connect whatever label from sub-network A associated with FOO to whatever label from sub-network B is associated with BAR" should be persistent. 8. Acknowledgments Loa Andersson, Eric Gray, David Sinicrope and Greg Mirsky contributed to the development of this document. 9. IANA Considerations This document does not require IANA action. 10. Security Considerations For a future version of this document. Allan et al., Expires August, 2012 [Page 9] Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-00 February 2012 11. References 11.1. Informative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosen et.al. Multiprotocol Label Switching Architecture, IETF RFC 3031, January 2001 [3] Kompella et.al. Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures, IETF RFC 4379, February 2006 [4] Mansfield et. al. Network Management Framework for MPLS-based Transport Networks, IETF RFC 5950, September 2010 [5] Caviglia, D., Bramanti, D., Li, D., and D. McDysan, "Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network", RFC 5493, April 2009. [6] Andersson et.al. LDP Specification, IETF RFC 5036, October 2007 [7] Minei, I. et.al. Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths, IETF RFC 6388 [8] Awduche et.al. RSVP-TE: Extensions to RSVP for LSP Tunnels, IETF RFC 3209, December 2001 [9] Berger et.al. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, IETF RFC 3471, January 2003 [10] Rosen et.al. BGP/MPLS IP Virtual Private Networks (VPNs), IETF RFC 4364, February 2006 [11] Swallow et.al. Avoiding Equal Cost Multipath Treatment in MPLS Networks, IETF RFC 4928, June 2007 [12] Bocci et.al. MPLS Generic Associated Channel, IETF RFC 5586, June 2009 [13] Nadeau et.al Pseudowire Virtual Circuit Connectivity Verification (VCCV) A Control Channel for Pseudowires, IETF RFC 5085, December 2007 Allan et al., Expires August, 2012 [Page 10] Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-00 February 2012 [14] Aissaoui et.al. Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping, IETF RFC 6310, July 2011 [15] Swallow et.al. MPLS Fault Management OAM, IETF RFC 6427 [16] Bryant et.al. MPLS-TP Linear Protection, IETF RFC 6378 [17] Frost et.al. MPLS Transport Profile Data Plane Architecture, IETF RFC 5960, August 2010 [18] Sprecher et.al. MPLS Transport Profile (MPLS-TP) Survivability Framework, IETF RFC 6372, September 2011 [19] Pan et.al. Fast Reroute Extensions to RSVP-TE for LSP Tunnels, IETF RFC 4090, May 2005 Authors' Addresses Dave Allan Ericsson Email: david.i.allan@ericsson.com Allan et al., Expires August, 2012 [Page 11]