Network Working Group L. Andersson Internet-Draft R. Martinotti Intended status: Standards Track Ericsson Expires: July 28, 2012 January 25, 2012 "Unified MPLS Framework" draft-martinotti-mpls-unified-mpls-fwk-01.txt Abstract This document is framework for Unified MPLS. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on July 28, 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. Andersson & Martinotti Expires July 28, 2012 [Page 1] Internet-Draft Unified MPLS Framework January 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation and Background . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3.1. MPLS Protocols and Packages . . . . . . . . . . . . . 5 1.3.2. MPLS Technology . . . . . . . . . . . . . . . . . . . 6 1.3.3. Topology Driven MPLS . . . . . . . . . . . . . . . . . 6 1.3.4. MPLS Traffic Engineering . . . . . . . . . . . . . . . 6 1.3.5. MPLS Transport Profile . . . . . . . . . . . . . . . . 7 1.3.6. Additional Terms and Acronyms . . . . . . . . . . . . 7 1.3.7. MPLS Terminology structure . . . . . . . . . . . . . . 8 2. Unified MPLS Requirements . . . . . . . . . . . . . . . . . . 13 2.1. Full Interoperability and Interworking . . . . . . . . . . 13 2.2. Common Data Plane . . . . . . . . . . . . . . . . . . . . 13 2.3. Common OAM . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4. Data Plane Agnostic . . . . . . . . . . . . . . . . . . . 13 2.5. Interworking . . . . . . . . . . . . . . . . . . . . . . . 13 3. Unified MPLS Overview . . . . . . . . . . . . . . . . . . . . 15 3.1. Unified MPLS Control Plane . . . . . . . . . . . . . . . . 15 3.2. Unified MPLS Data Plane . . . . . . . . . . . . . . . . . 15 3.3. Unified MPLS Management . . . . . . . . . . . . . . . . . 16 3.4. Unified MPLS OAM . . . . . . . . . . . . . . . . . . . . . 17 4. Interfaces and Interworking . . . . . . . . . . . . . . . . . 18 4.1. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. Network Layer Interworking . . . . . . . . . . . . . . . . 18 4.3. Service Layer Interworking . . . . . . . . . . . . . . . . 18 4.4. Network Overlay . . . . . . . . . . . . . . . . . . . . . 19 5. MPLS Resiliency . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. MPLS Recovery . . . . . . . . . . . . . . . . . . . . . . 20 5.2. MPLS Protection . . . . . . . . . . . . . . . . . . . . . 20 5.3. MPLS Survivability . . . . . . . . . . . . . . . . . . . . 20 6. Other Unified MPLS Considerations . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 10.2. Informative references . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Andersson & Martinotti Expires July 28, 2012 [Page 2] Internet-Draft Unified MPLS Framework January 2012 1. Introduction The term "Unified MPLS" indicates several different things: The ambition to continue to keep MPLS together as one single technology, base on a common architecture. The ambition to maximize interworking between different flavors of MPLS (MPLS Packages) within the MPLS technology The ambition that functionality developed for one of the MPLS Aggregate Packages should be re-useable within other MPLS Aggregate Packages, MPLS is a mature Internet technology that has been used over the last 18 years to give e.g. QoS, resiliency, scalability, virtualization, etc. to IP networks. Through e.g. Pseudowires and L2VPN development it has also been adapted to emulate legacy protocols such as Frame Relay, TDM, ATM and Ethernet. The development of the MPLS technology has been very rapid since the start, the last 4 to 5 years have not been an exception. In particular we have seen developments in OAM in order to meet transport environments requirements, specification of multicast techniques and over the last years new resiliency strategies have been deployed. Over the years it has become possible to distinguish different MPLS Packages, e.g.MPLS traffic Engineering (MPLS-TE), Topology Driven MPLS (MPLS-TD) and the Transport Profile of MPLS (MPLS-TP). Revision note: Version -01 has been updated after comments from several sources, especial we are grateful for comments tht has helped improve the structure of the document. We have als recieved comment to the effect "in the list in (now) section 1.3 you have missed" we have tried aqdd this information as best as we can. There is still some glaring holes that we need to cover and is open to input and participation driving the draft forward. 1.1. Motivation and Background Needless to say this very dynamic environment has put stress on the MPLS architecture. Another factor that contributed is that MPLS technology over the years has evolved to addresses almost all networking market segments. Andersson & Martinotti Expires July 28, 2012 [Page 3] Internet-Draft Unified MPLS Framework January 2012 Vendors that are only interested to incorporate one of the MPLS packages often tend to prioritize the development of one of the packages at the expense of the others, one typical example is the T-MPLS standardization that was started within ITU-T and rapidly developed into a separate technology. This in itself put stress on the MPLS architecture. The MPLS architecture has stood up surprisingly well, but there are a few things that need to be documented as part of the MPLS architecture, primarily on the OAM side, but also on MPLS multicast and traffic engineering. The time has come to take steps to bring the MPLS architecture together and create a unified MPLS architecture - an architecture and protocol suite that can operate end to end, with pieces that may be combined in a fashion that can meet the needs of the service provider according to their requirements and environment and not the limitations of the profiles. 1.2. Scope The term "Unified MPLS" has come to indicate that the environment where MPLS is used has been gradually changing over the years, it is highly likely that architectural updates are needed. This framework document addresses how the environment of RFC 3031 [RFC3031]has changed. MPLS started out as a set of tools to support IP networks, but over time developed to have much broader application than that. We have seen the development of IP-VPNs, L2VPNs, PWs for carrying non-IP payload, deployment of MPLS in networks where we don't even require or have IP in the forwarding plane. Starting with existing MPLS protocols, i.e. data plane, signaling (label distribution) protocols, routing, TE-extensions, OAM and the different management tools it is possible to build a surprisingly large number of viable MPLS deployments. For lack of a better name we have chosen to call the deployable MPLS constructs "packages". In Terminology (Section 1.3) we will elaborate on this terminology. This document discusses interworking between MPLS Packages on LSP level. Discussion of interworking between PWs is for further study. A number of standardization and technology development projects have extended MPLS in very different directions. In Unified MPLS we make two assumptions: Andersson & Martinotti Expires July 28, 2012 [Page 4] Internet-Draft Unified MPLS Framework January 2012 1. The Interworking potential between different MPLS Packages and MPLS Aggregate packages shall be maximized and that this is a design goal in all development and standardization of MPLS. 2. Functionality developed for one MPLS Aggregate Package, e.g. the MPLS-TP OAM tools developed in the joint project with ITU-T, shall be designed in such a way that it is re-useable within other MPLS (Aggregate) Packages. 1.3. Terminology In the "ontology" section (Section 1.3.7) an outline of this aspect of the MPLS terminology is given. 1.3.1. MPLS Protocols and Packages For the purpose of understanding the MPLS terminology structure we operate with four concepts; MPLS Protocols, MPLS Packages, MPLS Aggregate Packages and MPLS Technology. 1.3.1.1. MPLS Protocols We have a rather wide definition of "protocol", i.e. all the IETF protocols that specify MPLS behavior of the data, control and management plane. OAM is considered to be part of the data plane. 1.3.1.2. MPLS Packages An MPLS Package is a ordered collection of MPLS protocols put together because it can give you a desired functionality. One example would be running OSPF and LDP in your network to create a topology driven MPLS see Topology Driven MPLS (Section 1.3.3). 1.3.1.3. MPLS Aggregate Packages An MPLS Aggregate Package is a grouping of MPLS Packages. Packages that can be used to build MPLS network of identical functionality can be grouped into MPLS Aggregate Package. There is for example nothing that stops you from running Topology Driven MPLS (MPLS-TD) based on ISIS instead of OSPF; those two MPLS packages form together the MPLS-TD Aggregate package. Note: We need to revisit "identical functionality" in the paragraph above and see if there is a better way do describe this. We see that it is possible to form three different MPLS Aggregate Packages. First we have MPLS Traffic Engineering (MPLS-TE), Topology Driven MPLS (MPLS-TD) and the MPLS Transport Profile (MPLS-TP). Andersson & Martinotti Expires July 28, 2012 [Page 5] Internet-Draft Unified MPLS Framework January 2012 In - whichever section it will be - a somewhat simplified overview of MPLS Protocols, Packages and Aggregate Packages. 1.3.2. MPLS Technology The "MPLS" or "MPLS Technology" is a the sum of the MPLS protocols and the method of grouping them to MPLS Packages and Aggregate MPLS Packages as illustrated in the - Appendix. The MPLS technology is also scoped, described and explained in a number of documents; such as applicability statements, requirements and frameworks. Though those document are not part of the Standards Track they are important as they gives a comprehensive view of the MPLS Technology. 1.3.3. Topology Driven MPLS We talk about Topology Driven MPLS (MPLS-TD) when the protocols establishing LSPs are limited to use the topology information created by IP routing protocols; i.e. packets sent over an MPLS LSP will traverse the network over the same path as it would have taken if the Shortest Path IP forwarding had been used. MPLS-TD consist of at least two different MPLS Packages, depending if ISIS or OSPF is used as the routing protocol. LDP is almost the only signaling protocol that is used in this type of network. Note: It is technically possible to use other routing protocols, e.g. Routing Information Protocol (RIP) RFC 2453 [RFC2453] or even static configuration or routes. However use of RIP or static routes in MPLS is very limited, and for all practical purposes these cases can be left aside. 1.3.4. MPLS Traffic Engineering We talk about MPLS Traffic Engineering (MPLS-TE) when other parameters than just the shortest path is taken into consideration when deciding on how and where an LSP should be set up. By far the most common criteria are available BW and explicit routing, this explains why the RSVP-TE protocol was well suited to be adapted as MPLS-TE signaling protocol. Deciding how many MPLS-TE Packages there are is slightly harder than for the MPLS-TD. There are two and only two routing protocols - OSPF-TE and ISIS-TE. For the signaling protocols the situation is a bit ambivalent; the Andersson & Martinotti Expires July 28, 2012 [Page 6] Internet-Draft Unified MPLS Framework January 2012 MPLS developed a RSVP-TE for MPLS traffic engineering RFC 3209 [RFC3209]. When the RSVP-TE was "generalized" for Generalized MPLS (GMPLS) the intention was that the more specific objects should be possible to use, but for the Label object this was never achieved. One could therefore say that we have two different signaling protocols. 1.3.5. MPLS Transport Profile The MPLS Transport Profile (MPLS-TP) is the latest addition of the MPLS Aggregate Packages. It is an extension of MPLS to meet the requirements from transport networks. There are five different MPLS Packages for MPLS-TP Note: We have a comment that we also have a hybrid package, when both an NMS and and an CP is used. o NMS Driven MPLS-TP (ND MPLS-TP), LSPs, PWs and segments is set up and configured from an NMS o Control Plane driven MPLS (CD MPLS-TP), LSPs, PWs and segments is set up and configured from the control plane. There are two variants of CD MPLS-TP depending on which routing protocol that is used; for CD MPLS-TP there is a decision to use the GMPLS version of RSVP-TE. * based on RSVP-TE and OSPF-TE * based on RSVP-TE and ISIS-TE The fourth variant is MPLS-TP P2MP configured from an NMS The fifth variant is when the MPLS-TP P2MP is configured from a control plane using the MPLS signaling and routing protocols. 1.3.6. Additional Terms and Acronyms This section lists terms and acronyms used in this document. 1.3.6.1. New terms Control Plane Driven - LSPs are set up and configured from the control plane. This is true for almost all MPLS, but the Control Plane Driven terminology originates from the MPLS-TP project. Andersson & Martinotti Expires July 28, 2012 [Page 7] Internet-Draft Unified MPLS Framework January 2012 NMS Driven - LSPs are set up and configured from an NMS This is the mode Transport Networks has been operated in traditionally. 1.3.6.2. Acronyms CD MPLS-TP - Control Plane Driven MPLS-TP CLI - Command Line Interface EM - Element Manager LCT - (correct expansion??) MPLS-TD - Topology Driven MPLS MPLS-TE - Traffic Engineered MPLS MPLS-TP - MPLS for Transport Networks (MPLS Transport Profile) ND MPLS-TP - NMS Driven MPLS-TP NE - Network Element NMS - Network Management System TE P2MP - Traffic Engineered P2MP 1.3.7. MPLS Terminology structure In the abbreviated table below a way of thinking about the relationship between the MPLS RFCs, MPLS protocols, MPLS packages and MPLS Aggregate Packages is outlined. We take the approach that RFCs can be grouped into protocols, and that protocols may form MPLS packages, which in turn can be grouped into Aggregate Packages. In talking about "MPLS RFCs" and "MPLS protocols" we do so in a wide sense, i.e. RFCs and protocols that might be used in MPLS networks. Most of those are developed by working groups that we listed as "MPLS working groups" in RFC 4929 [RFC4929], but there are also other protocols that are used and necessary in some MPLS networks, e.g. the IGPs that were developed in other working groups. We have added NMS Configuration and MPLS Data Plane, even though they they are not "protocols" of the same flavor as the other protocols Andersson & Martinotti Expires July 28, 2012 [Page 8] Internet-Draft Unified MPLS Framework January 2012 MPLS Terminology Structure - a strawman ontology --------------------------------------------------------------------- MPLS RFCs (examples) RFC5036 RFC3478 RFC3479 RFC3209 RFC3477 RFC6428 RFC3031 RFC3032 RFC3033 RFC3034 RFC3035 RFC3038 RFC3107 RFC3209 RFC3270 RFC3473 RFC3477 RFC3478 RFC3479 RFC3811 RFC3812 RFC3813 RFC3814 RFC3815 RFC4023 RFC4090 RFC4182 RFC4201 RFC4206 RFC4220 RFC4368 RFC4379 RFC5420 RFC4561 RFC4781 RFC4817 RFC4875 RFC4950 RFC5283 RFC5330 RFC5331 RFC5332 RFC5462 RFC%%61 RFC5586 RFC5710 RRFC5711 RFC5712 RFC5718 RFC5918 RFC5919 RFC5960 RFC6178 RFC6370 RFC6372 RFC6374 RFC6375 RFC6378 RFC6388 RFC6424 (mLDP) RFC5316 RFC5392 etc RFC2328 RFC2370 RFC1195 RFC3784 RFC4205 RFC5880 RFC5884 (depending on how one counts the number of RFCs may vary) --------------------------------------------------------------------- MPLS Protocols +----------+----------+----------+----------+----------+ | LDP | OSPF | ISIS | RSVP-TE | LSP-PING | +----------+----------+----------+----------+----------+ | RFC5036 | RFC2328 | RFC1195 | RFC5712 | RFC6424 | +----------+----------+----------+----------+----------+ | RFC6388 | | | RFC5711 | RFC4379 | +----------+----------+----------+----------+----------+ | RFC5919 | | | RFC5710 | | +----------+----------+----------+----------+----------+ | RFC5918 | | | RFC5330 | | +----------+----------+----------+----------+----------+ | RFC5561 | | | RFC4875 | | +----------+----------+----------+----------+----------+ | (mLDP) | | | RFC3209 | | +----------+----------+----------+----------+----------+ | etc | | | etc | | +----------+----------+----------+----------+----------+ +----------+----------+----------+----------+----------+ Andersson & Martinotti Expires July 28, 2012 [Page 9] Internet-Draft Unified MPLS Framework January 2012 | MPLS-OAM | OSPF-TE | ISIS-TE | BFD | NMS Conf | +----------+----------+----------+----------+----------+ | RFC6378 | RFC2370 | RFC3784 | RFC5880 | nil | +----------+----------+----------+----------+----------+ | RFC6375 | RFC3471 | RFC5316 | RFC5884 | | +----------+----------+----------+----------+----------+ | RFC6374 | RFC3473 | RFC4205 | | | +----------+----------+----------+----------+----------+ | RFC6372 | RFC4203 | | | | +----------+----------+----------+----------+----------+ | RFC6370 | | | | | +----------+----------+----------+----------+----------+ | RFC5586 | | | | | +----------+----------+----------+----------+----------+ | etc | | | | | +----------+----------+----------+----------+----------+ +----------+----------+----------+----------+----------+ | MPLS-DP | MPLS-NM | BGP | | | +----------+----------+----------+----------+----------+ | RFC6178 | RFC5718 | RFC3107 | | | +----------+----------+----------+----------+----------+ | RFC5960 | RFC4368 | | | | +----------+----------+----------+----------+----------+ | RFC5462 | RFC4220 | | | | +----------+----------+----------+----------+----------+ | RFC4182 | RFC3815 | | | | +----------+----------+----------+----------+----------+ | RFC4023 | RFC3814 | | | | +----------+----------+----------+----------+----------+ | RFC3473 | RFC3813 | | | | +----------+----------+----------+----------+----------+ | etc | etc | | | | +----------+----------+----------+----------+----------+ --------------------------------------------------------------------- MPLS Packages +-----------+-----------+-----------+-----------+-----------+ | MPLS-TD 1 | MPLS-TD 2 | MPLS-TD | MPLS-TD | GMPLS 1 | | | | P2MP 1 | P2MP 2 | | +===========+===========+===========+===========+===========+ | ISIS | OSPF | ISIS | OSPF | OSPF-TE | +-----------+-----------+-----------+-----------+-----------+ | LDP | LDP | LDP | LDP | RSVP-TE | +-----------+-----------+-----------+-----------+-----------+ Andersson & Martinotti Expires July 28, 2012 [Page 10] Internet-Draft Unified MPLS Framework January 2012 | | | RFC6388 | RFC6388 | | | | | (mLDP) | (mLDP) | | +-----------+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+-----------+ | MPLS-TD | | | | | | BGP | | | | | +===========+===========+===========+===========+===========+ | BGP | | | | | | RFC3107 | | | | | +-----------+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+-----------+ | MPLS-TE 1 | MPLS-TE 2 | MPLS-TE | MPLS-TE | GMPLS 2 | | | | P2MP 1 | P2MP 2 | | +===========+===========+===========+===========+===========+ | ISIS-TE | OSPF-TE | ISIS-TE | OSPF-TE | ISIS-TE | +-----------+-----------+-----------+-----------+-----------+ | RSVP-TE | RSVP-TE | RSVP-TE | RSVP-TE | RSVP-TE | +-----------+-----------+-----------+-----------+-----------+ | | | RFC4875 | RFC4875 | | +-----------+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+-----------+ | MPLS-TP 1 | MPLS-T2 2 | MPLS-TP 3 | MPLS-TP 4 | MPLS-TP 5 | |ND MPLS-TP |CD MPLS-TP | CD-MPLS-TP| P2MP TP | P2MP TP | +===========+===========+===========+===========+===========+ | NMS conf | OSPF-TE | ISIS-TE | static | OSPF-TE | +-----------+-----------+-----------+-----------+-----------+ | MPLSP OAM | RSVP-TE | RSVP-TE | RSVP-TE | RSVP-TE | +-----------+-----------+-----------+-----------+-----------+ | | MPLS OAM | MPLS OAM | MPLS OAM | MPLS OAM | +-----------+-----------+-----------+-----------+-----------+ --------------------------------------------------------------------- MPLS Aggregate Packages +--------------+--------------+--------------+ | MPLS-TD | MPLS-TE | MPLS-TP | | | | | +==============+==============+==============+ | MPLS-TD 1 | MPLS-TE 1 | MPLS-TP 1 | Andersson & Martinotti Expires July 28, 2012 [Page 11] Internet-Draft Unified MPLS Framework January 2012 | | | ND MPLS-TP | +--------------+--------------+--------------+ | MPLS-TD 2 | MPLS-TE 2 | MPLS-TP 2 | | | | CD MPLS-TP | +--------------+--------------+--------------+ | MPLS-TD | MPLS-TE | MPLS-TP 3 | | P2MP 1 | P2MP 1 | CD MPLS-TP | +--------------+--------------+--------------+ | MPLS-TD | MPLS-TE | MPLS-TP 4 | | P2MP 2 | P2MP 2 | P2MP TP | +--------------+--------------+--------------+ | | GMPLS 1 | | | | | | +--------------+--------------+--------------+ | | GMPLS 2 | | | | | | +--------------+--------------+--------------+ --------------------------------------------------------------------- MPLS Technology --------------------------------------------------------------------- Andersson & Martinotti Expires July 28, 2012 [Page 12] Internet-Draft Unified MPLS Framework January 2012 2. Unified MPLS Requirements This section list the high level requirements for Unified MPLS. 2.1. Full Interoperability and Interworking One important aspect of Unified MPLS is to promote interoperability and interworking between different flavors of MPLS. Unified MPLS addresses the problem of cross-MPLS interoperation and interworking. Requirement: Unified MPLS SHALL guarantee full interoperability between all MPLS packages, i.e. SHALL e.g. be possible to start an LSP in an MPLS-TP network, cross MPLS-TE network and terminate it in a MPLS-TD network. 2.2. Common Data Plane Requirement: The actions taken on a MPLS encapsulated packet relative to the label on top of the label stack, SHALL be the same regardless if the LSP has been set up using any of the MPLS routing and signaling protocols or if it has been established manually or from an NMS. 2.3. Common OAM OAM is defined as part of the data plane. One goal with Unified MPLS is that it shall be possible to use MPLS-TP OAM for all MPLS packages. Requirement: Given that MPLS-TP OAM is used there SHALL NOT, from the point of view of an MPLS encapsulated packet traversing the data plane of a MPLS Network, be any differences depending on whether the LSP has been set up using any of the MPLS routing and signaling protocols or if it has been established manually or from an NMS. 2.4. Data Plane Agnostic Requirement: The relationship between LSPs and the payload transported on those LSPs, i.e. PWs, LSPs and IP, SHALL be the same regardless if the payload is transported by one or the other of the MPLS packages. 2.5. Interworking Requirement: There SHALL be no limitations in the possibilities to hand over payload from one LSP to another regardless of how the LSPs has been established, i.e. it SHALL be possible to carry a PW on a MPLS-TP or MPLS-TD segment and then hand it over to a MPLS-TE LSP and Andersson & Martinotti Expires July 28, 2012 [Page 13] Internet-Draft Unified MPLS Framework January 2012 vice versa. Andersson & Martinotti Expires July 28, 2012 [Page 14] Internet-Draft Unified MPLS Framework January 2012 3. Unified MPLS Overview This section should contain a high-level overview of Unified MPLS. Here we discuss interfacing different mpls types! QUESTION: Do we have to consider also co-existence of different packages (e.g. CD-MPLS-TP and MPLS-TE)? Do we want to consider a network being physically partitioned or logically too? QUESTION: Do we want to describe the possibility of reusing tools/ protocols defined into one package into other ones? 3.1. Unified MPLS Control Plane Unified MPLS comprises a set of protocols for implementing a Control Plane for Network Layer, for Routing and LSP label distribution. We consider the following routing protocols: OSPF and ISIS and their versions with Traffic Engineering extensions. We also consider the following LSP label distribution protocols: LDP and RSVP-TE (and its extensions for MPLS-TP). Each package having a control plane uses a combination of them. We also consider the possibility where PW level is setup and maintained via tLDP. One aim of Unified MPLS is to consider the Control Plane implications of putting two network domains in relationship, where one or both of them implements a control plane; not all the combinations may interwork in principle. Further considerations are done in Section 4.4. 3.2. Unified MPLS Data Plane Unified MPLS comprises a standard MPLS data plane [RFC3031]. The following information is relevant to Unified MPLS. The forwarding functions comprise the mechanisms required for forwarding the encapsulated native service traffic over an MPLS network, for example, LSP and PW labels. MPLS label switching operations and Time-to-Live (TTL) processing procedures are used, as defined in [RFC3031], [RFC3032], [RFC3443] and [RFC5921]. SS-PW and MS-PW forwarding operations are used, as defined in [RFC3985] and [RFC5659]. Per-platform label space is used for PWs. Either per-platform, per- Andersson & Martinotti Expires July 28, 2012 [Page 15] Internet-Draft Unified MPLS Framework January 2012 interface, or other context-specific label space [RFC5331] may be used for LSPs. MPLS forwarding is based on the label that identifies the path (LSP or PW). The label value specifies the processing operation to be performed by the next hop at that level of encapsulation. A swap of this label is an atomic operation in which the contents of the packet after the swapped label are opaque to the forwarder. The only event that interrupts a swap operation is TTL expiry. TTL expiry, which is a fundamental architectural construct of MPLS to be taken into account when designing protocol extensions (such as those for OAM) that require packets to be sent to an intermediate LSR. Further processing to determine the context of a packet occurs when a swap operation is interrupted in this manner, or a pop operation exposes a specific reserved label at the top of the stack (including the GAL). Otherwise, the packet is forwarded according to the procedures in [RFC3032]. MPLS Differentiated Services (Diffserv) architecture [RFC3270] is the suggested mode of supporting Quality of Services in Unified MPLS. Both E-LSP and L-LSP MPLS Diffserv modes are supported. Multicast MPLS is left for further study within Unified MPLS. 3.3. Unified MPLS Management Here we want to describe the possible methods for Management of Unified MPLS. Commonly used methods, such as CLI, may be used in conjunction with LCT, EM, NMS, as described in [RFC5950]. Most important functions related to Management are: provisioning of network layer and service layer, fault and performance monitoring, inventory. In several profiles of MPLS, provisioning of network layer and service layer is done by means of Control Plane. Where Management plane only is used for provisioning (e.g. in ND-MPLS-TP), routing, Path Computation Element, label distribution, configuration of the parameters for network and service layer are done via network management tools. Where several subnetworks are deployed, it may happen that only a subset of them is operated via Management, while another is operated via Control Plane. The dependencies of the two has to be analysed. Andersson & Martinotti Expires July 28, 2012 [Page 16] Internet-Draft Unified MPLS Framework January 2012 3.4. Unified MPLS OAM OAM is used to perform functions of operation, administration and maintenance (a comprehensive description of OAM functions is described in [RFC6291]). These functions are applicable both to LSP and PW. Among all the functions provided by OAM, fault management and performance monitoring are used to have a common method to verify the behavior of a network domain and a single mean to monitor the different kinds of service being provided. OAM for MPLS has been defined in [LIST-OF-RFC-OF-OAM-FOR-LSP], especially because of the requirements of MPLS-TP. OAM for PW has been defined in [LIST-OF-RFC-OF-OAM-FOR-PW]. One critical objective of Unified MPLS is to describe how these tools can be used in a multi-domain MPLS network, where different packages can be deployed. Andersson & Martinotti Expires July 28, 2012 [Page 17] Internet-Draft Unified MPLS Framework January 2012 4. Interfaces and Interworking Where two or more subnetworks (or profiles instances) are deployed within an operator network, it is important to consider the interface between each pair of them. Peering relationship is where the two subnetworks are at the same level with respect to the end-to-end service being provided. Peering relationship may happen at LSP, PW or client service level. Overlay relationship is where one subnetwork is client of the other one, so that the server subnetwork provides connectivity to part of the client one. In this section we discuss the most important interfaces and subnetwork interworking. 4.1. Interfaces Several packages are considered within MPLS Technology. Anyhow there is not yet a guideline on how to use a combination of different packages in a single operator network. With Unified MPLS we want to describe the interfaces between the different packages. The number of the possible interfaces is quite high, so a brute force approach for their description is not beneficial to the reader. An objective of Unified MPLS is to start the analysis with the most common interworking scenarios. The interface between two domains may be a node or a link. The two cases may lead to different requirements and behaviors at the interface. It may happen that one or several interfaces (of the same kind) happen between two domains. 4.2. Network Layer Interworking This document uses the term Network Layer in the same sense as it is used in [RFC3031] and [RFC3032]. Two peering network domains (each one implementing one instance of any MPLS package) interwork at Network Layer when they are configured to interconnect at LSP or PW level. LSP stitching and MS-PW are used, depending on the level chosen. LSP stitching may be used for any client signal encapsulated into the end-to-end LSP (MPLS, PW, IP), while MS-PW can only be used for PW encapsulated signals. 4.3. Service Layer Interworking Service interface (UNI and NNI) reference models are described in [RFC5921] and further analyzed in [RFC6125]. Two peering network domains (each one implementing one instance of any MPLS package) interwork at Service Layer when they are configured to interconnect at client service level. In case of border link Andersson & Martinotti Expires July 28, 2012 [Page 18] Internet-Draft Unified MPLS Framework January 2012 interconnecting the two domains, it can be named UNI in [RFC6125] terminology. In case of border node interconnecting the two domains, Termination mode applies. 4.4. Network Overlay When two network domains are in Overlay relationship, in principle there isn't any interworking between them. Anyhow there are few aspects to be taken into account, at least from CP and Fault Management point of view. CP aspects has to be considered when the client network domain is CD (it implements a CP). If the server network domain is CD, there is the possibility to interact between the two CPs. if the server network is ND, then the resources for the client domain must be pre- allocated. In case OAM tool set is used in both client and server network domain, there is the possibility to propagate fault indication, happened within the server domain, into the client domain. One Unified MPLS aim is also to specific constraints given by the used packages (E.g. if a domain using MPLS-TE is client of a domain using MPLS-TD, bandwidth requirements of the client layer may not be guaranteed. Andersson & Martinotti Expires July 28, 2012 [Page 19] Internet-Draft Unified MPLS Framework January 2012 5. MPLS Resiliency This section will dicuss different aspects of MPLS resiliency, like protection, suvivability and recovery. 5.1. MPLS Recovery Note: Text needed! 5.2. MPLS Protection Note: Text needed! 5.3. MPLS Survivability Note: Text needed! Andersson & Martinotti Expires July 28, 2012 [Page 20] Internet-Draft Unified MPLS Framework January 2012 6. Other Unified MPLS Considerations It is quite possible that Unified MPLS should also address a number of other aspects of MPLS. Andersson & Martinotti Expires July 28, 2012 [Page 21] Internet-Draft Unified MPLS Framework January 2012 7. Security Considerations Security considerations to be added. Andersson & Martinotti Expires July 28, 2012 [Page 22] Internet-Draft Unified MPLS Framework January 2012 8. IANA considerations There are no IANA considerations for this document (at least currently) an IANA section will be added as necessary. Andersson & Martinotti Expires July 28, 2012 [Page 23] Internet-Draft Unified MPLS Framework January 2012 9. Acknowledgments We have recieved valuable feeback from several people working with adapting and utilizing MPLS in their networks. Andersson & Martinotti Expires July 28, 2012 [Page 24] Internet-Draft Unified MPLS Framework January 2012 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002. [RFC4929] Andersson, L. and A. Farrel, "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, June 2007. [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. 10.2. Informative references [I-D.bryant-mpls-tp-jwt-report] Bryant, S. and L. Andersson, "JWT Report on MPLS Architectural Considerations for a Transport Profile", draft-bryant-mpls-tp-jwt-report-00 (work in progress), July 2008. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010. Andersson & Martinotti Expires July 28, 2012 [Page 25] Internet-Draft Unified MPLS Framework January 2012 Authors' Addresses Loa Andersson Ericsson Email: loa@pi.nu Riccardo Martinotti Ericsson Email: riccardo.martinotti@ericsson.com Andersson & Martinotti Expires July 28, 2012 [Page 26]