idnits 2.17.1 draft-martinotti-mpls-unified-mpls-fwk-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 25, 2012) is 4475 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3443' is mentioned on line 622, but not defined == Missing Reference: 'RFC3985' is mentioned on line 626, but not defined == Missing Reference: 'RFC5659' is mentioned on line 626, but not defined == Missing Reference: 'RFC5331' is mentioned on line 629, but not defined == Missing Reference: 'RFC3270' is mentioned on line 648, but not defined == Missing Reference: 'RFC5950' is mentioned on line 658, but not defined == Missing Reference: 'RFC6291' is mentioned on line 678, but not defined == Missing Reference: 'LIST-OF-RFC-OF-OAM-FOR-LSP' is mentioned on line 684, but not defined == Missing Reference: 'LIST-OF-RFC-OF-OAM-FOR-PW' is mentioned on line 686, but not defined == Missing Reference: 'RFC6125' is mentioned on line 740, but not defined ** Obsolete undefined reference: RFC 6125 (Obsoleted by RFC 9525) == Unused Reference: 'RFC2119' is defined on line 808, but no explicit reference was found in the text == Unused Reference: 'RFC3429' is defined on line 825, but no explicit reference was found in the text == Unused Reference: 'RFC5586' is defined on line 835, but no explicit reference was found in the text == Unused Reference: 'I-D.bryant-mpls-tp-jwt-report' is defined on line 840, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3429 Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Andersson 3 Internet-Draft R. Martinotti 4 Intended status: Standards Track Ericsson 5 Expires: July 28, 2012 January 25, 2012 7 "Unified MPLS Framework" 8 draft-martinotti-mpls-unified-mpls-fwk-01.txt 10 Abstract 12 This document is framework for Unified MPLS. 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on July 28, 2012. 31 Copyright Notice 33 Copyright (c) 2012 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Motivation and Background . . . . . . . . . . . . . . . . 3 50 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 52 1.3.1. MPLS Protocols and Packages . . . . . . . . . . . . . 5 53 1.3.2. MPLS Technology . . . . . . . . . . . . . . . . . . . 6 54 1.3.3. Topology Driven MPLS . . . . . . . . . . . . . . . . . 6 55 1.3.4. MPLS Traffic Engineering . . . . . . . . . . . . . . . 6 56 1.3.5. MPLS Transport Profile . . . . . . . . . . . . . . . . 7 57 1.3.6. Additional Terms and Acronyms . . . . . . . . . . . . 7 58 1.3.7. MPLS Terminology structure . . . . . . . . . . . . . . 8 59 2. Unified MPLS Requirements . . . . . . . . . . . . . . . . . . 13 60 2.1. Full Interoperability and Interworking . . . . . . . . . . 13 61 2.2. Common Data Plane . . . . . . . . . . . . . . . . . . . . 13 62 2.3. Common OAM . . . . . . . . . . . . . . . . . . . . . . . . 13 63 2.4. Data Plane Agnostic . . . . . . . . . . . . . . . . . . . 13 64 2.5. Interworking . . . . . . . . . . . . . . . . . . . . . . . 13 65 3. Unified MPLS Overview . . . . . . . . . . . . . . . . . . . . 15 66 3.1. Unified MPLS Control Plane . . . . . . . . . . . . . . . . 15 67 3.2. Unified MPLS Data Plane . . . . . . . . . . . . . . . . . 15 68 3.3. Unified MPLS Management . . . . . . . . . . . . . . . . . 16 69 3.4. Unified MPLS OAM . . . . . . . . . . . . . . . . . . . . . 17 70 4. Interfaces and Interworking . . . . . . . . . . . . . . . . . 18 71 4.1. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 18 72 4.2. Network Layer Interworking . . . . . . . . . . . . . . . . 18 73 4.3. Service Layer Interworking . . . . . . . . . . . . . . . . 18 74 4.4. Network Overlay . . . . . . . . . . . . . . . . . . . . . 19 75 5. MPLS Resiliency . . . . . . . . . . . . . . . . . . . . . . . 20 76 5.1. MPLS Recovery . . . . . . . . . . . . . . . . . . . . . . 20 77 5.2. MPLS Protection . . . . . . . . . . . . . . . . . . . . . 20 78 5.3. MPLS Survivability . . . . . . . . . . . . . . . . . . . . 20 79 6. Other Unified MPLS Considerations . . . . . . . . . . . . . . 21 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 81 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 85 10.2. Informative references . . . . . . . . . . . . . . . . . . 25 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 88 1. Introduction 90 The term "Unified MPLS" indicates several different things: 92 The ambition to continue to keep MPLS together as one single 93 technology, base on a common architecture. 95 The ambition to maximize interworking between different flavors of 96 MPLS (MPLS Packages) within the MPLS technology 98 The ambition that functionality developed for one of the MPLS 99 Aggregate Packages should be re-useable within other MPLS Aggregate 100 Packages, 102 MPLS is a mature Internet technology that has been used over the last 103 18 years to give e.g. QoS, resiliency, scalability, virtualization, 104 etc. to IP networks. 106 Through e.g. Pseudowires and L2VPN development it has also been 107 adapted to emulate legacy protocols such as Frame Relay, TDM, ATM and 108 Ethernet. 110 The development of the MPLS technology has been very rapid since the 111 start, the last 4 to 5 years have not been an exception. In 112 particular we have seen developments in OAM in order to meet 113 transport environments requirements, specification of multicast 114 techniques and over the last years new resiliency strategies have 115 been deployed. 117 Over the years it has become possible to distinguish different MPLS 118 Packages, e.g.MPLS traffic Engineering (MPLS-TE), Topology Driven 119 MPLS (MPLS-TD) and the Transport Profile of MPLS (MPLS-TP). 121 Revision note: Version -01 has been updated after comments from 122 several sources, especial we are grateful for comments tht has helped 123 improve the structure of the document. We have als recieved comment 124 to the effect "in the list in (now) section 1.3 you have missed" we 125 have tried aqdd this information as best as we can. 127 There is still some glaring holes that we need to cover and is open 128 to input and participation driving the draft forward. 130 1.1. Motivation and Background 132 Needless to say this very dynamic environment has put stress on the 133 MPLS architecture. Another factor that contributed is that MPLS 134 technology over the years has evolved to addresses almost all 135 networking market segments. 137 Vendors that are only interested to incorporate one of the MPLS 138 packages often tend to prioritize the development of one of the 139 packages at the expense of the others, one typical example is the 140 T-MPLS standardization that was started within ITU-T and rapidly 141 developed into a separate technology. This in itself put stress on 142 the MPLS architecture. 144 The MPLS architecture has stood up surprisingly well, but there are a 145 few things that need to be documented as part of the MPLS 146 architecture, primarily on the OAM side, but also on MPLS multicast 147 and traffic engineering. 149 The time has come to take steps to bring the MPLS architecture 150 together and create a unified MPLS architecture - an architecture and 151 protocol suite that can operate end to end, with pieces that may be 152 combined in a fashion that can meet the needs of the service provider 153 according to their requirements and environment and not the 154 limitations of the profiles. 156 1.2. Scope 158 The term "Unified MPLS" has come to indicate that the environment 159 where MPLS is used has been gradually changing over the years, it is 160 highly likely that architectural updates are needed. This framework 161 document addresses how the environment of RFC 3031 [RFC3031]has 162 changed. MPLS started out as a set of tools to support IP networks, 163 but over time developed to have much broader application than that. 164 We have seen the development of IP-VPNs, L2VPNs, PWs for carrying 165 non-IP payload, deployment of MPLS in networks where we don't even 166 require or have IP in the forwarding plane. 168 Starting with existing MPLS protocols, i.e. data plane, signaling 169 (label distribution) protocols, routing, TE-extensions, OAM and the 170 different management tools it is possible to build a surprisingly 171 large number of viable MPLS deployments. 173 For lack of a better name we have chosen to call the deployable MPLS 174 constructs "packages". In Terminology (Section 1.3) we will 175 elaborate on this terminology. 177 This document discusses interworking between MPLS Packages on LSP 178 level. Discussion of interworking between PWs is for further study. 180 A number of standardization and technology development projects have 181 extended MPLS in very different directions. In Unified MPLS we make 182 two assumptions: 184 1. The Interworking potential between different MPLS Packages and 185 MPLS Aggregate packages shall be maximized and that this is a 186 design goal in all development and standardization of MPLS. 188 2. Functionality developed for one MPLS Aggregate Package, e.g. the 189 MPLS-TP OAM tools developed in the joint project with ITU-T, 190 shall be designed in such a way that it is re-useable within 191 other MPLS (Aggregate) Packages. 193 1.3. Terminology 195 In the "ontology" section (Section 1.3.7) an outline of this aspect 196 of the MPLS terminology is given. 198 1.3.1. MPLS Protocols and Packages 200 For the purpose of understanding the MPLS terminology structure we 201 operate with four concepts; MPLS Protocols, MPLS Packages, MPLS 202 Aggregate Packages and MPLS Technology. 204 1.3.1.1. MPLS Protocols 206 We have a rather wide definition of "protocol", i.e. all the IETF 207 protocols that specify MPLS behavior of the data, control and 208 management plane. OAM is considered to be part of the data plane. 210 1.3.1.2. MPLS Packages 212 An MPLS Package is a ordered collection of MPLS protocols put 213 together because it can give you a desired functionality. One 214 example would be running OSPF and LDP in your network to create a 215 topology driven MPLS see Topology Driven MPLS (Section 1.3.3). 217 1.3.1.3. MPLS Aggregate Packages 219 An MPLS Aggregate Package is a grouping of MPLS Packages. Packages 220 that can be used to build MPLS network of identical functionality can 221 be grouped into MPLS Aggregate Package. There is for example nothing 222 that stops you from running Topology Driven MPLS (MPLS-TD) based on 223 ISIS instead of OSPF; those two MPLS packages form together the 224 MPLS-TD Aggregate package. 226 Note: We need to revisit "identical functionality" in the paragraph 227 above and see if there is a better way do describe this. 229 We see that it is possible to form three different MPLS Aggregate 230 Packages. First we have MPLS Traffic Engineering (MPLS-TE), Topology 231 Driven MPLS (MPLS-TD) and the MPLS Transport Profile (MPLS-TP). 233 In - whichever section it will be - a somewhat simplified overview of 234 MPLS Protocols, Packages and Aggregate Packages. 236 1.3.2. MPLS Technology 238 The "MPLS" or "MPLS Technology" is a the sum of the MPLS protocols 239 and the method of grouping them to MPLS Packages and Aggregate MPLS 240 Packages as illustrated in the - Appendix. 242 The MPLS technology is also scoped, described and explained in a 243 number of documents; such as applicability statements, requirements 244 and frameworks. Though those document are not part of the Standards 245 Track they are important as they gives a comprehensive view of the 246 MPLS Technology. 248 1.3.3. Topology Driven MPLS 250 We talk about Topology Driven MPLS (MPLS-TD) when the protocols 251 establishing LSPs are limited to use the topology information created 252 by IP routing protocols; i.e. packets sent over an MPLS LSP will 253 traverse the network over the same path as it would have taken if the 254 Shortest Path IP forwarding had been used. 256 MPLS-TD consist of at least two different MPLS Packages, depending if 257 ISIS or OSPF is used as the routing protocol. LDP is almost the only 258 signaling protocol that is used in this type of network. 260 Note: It is technically possible to use other routing protocols, e.g. 261 Routing Information Protocol (RIP) RFC 2453 [RFC2453] or even static 262 configuration or routes. However use of RIP or static routes in MPLS 263 is very limited, and for all practical purposes these cases can be 264 left aside. 266 1.3.4. MPLS Traffic Engineering 268 We talk about MPLS Traffic Engineering (MPLS-TE) when other 269 parameters than just the shortest path is taken into consideration 270 when deciding on how and where an LSP should be set up. By far the 271 most common criteria are available BW and explicit routing, this 272 explains why the RSVP-TE protocol was well suited to be adapted as 273 MPLS-TE signaling protocol. 275 Deciding how many MPLS-TE Packages there are is slightly harder than 276 for the MPLS-TD. 278 There are two and only two routing protocols - OSPF-TE and ISIS-TE. 280 For the signaling protocols the situation is a bit ambivalent; the 281 MPLS developed a RSVP-TE for MPLS traffic engineering RFC 3209 282 [RFC3209]. When the RSVP-TE was "generalized" for Generalized MPLS 283 (GMPLS) the intention was that the more specific objects should be 284 possible to use, but for the Label object this was never achieved. 285 One could therefore say that we have two different signaling 286 protocols. 288 1.3.5. MPLS Transport Profile 290 The MPLS Transport Profile (MPLS-TP) is the latest addition of the 291 MPLS Aggregate Packages. It is an extension of MPLS to meet the 292 requirements from transport networks. 294 There are five different MPLS Packages for MPLS-TP 296 Note: We have a comment that we also have a hybrid package, when both 297 an NMS and and an CP is used. 299 o NMS Driven MPLS-TP (ND MPLS-TP), LSPs, PWs and segments is set up 300 and configured from an NMS 302 o Control Plane driven MPLS (CD MPLS-TP), LSPs, PWs and segments is 303 set up and configured from the control plane. 305 There are two variants of CD MPLS-TP depending on which routing 306 protocol that is used; for CD MPLS-TP there is a decision to use 307 the GMPLS version of RSVP-TE. 309 * based on RSVP-TE and OSPF-TE 311 * based on RSVP-TE and ISIS-TE 313 The fourth variant is MPLS-TP P2MP configured from an NMS 315 The fifth variant is when the MPLS-TP P2MP is configured from a 316 control plane using the MPLS signaling and routing protocols. 318 1.3.6. Additional Terms and Acronyms 320 This section lists terms and acronyms used in this document. 322 1.3.6.1. New terms 324 Control Plane Driven - 325 LSPs are set up and configured from the control plane. This is true 326 for almost all MPLS, but the Control Plane Driven terminology 327 originates from the MPLS-TP project. 329 NMS Driven - 330 LSPs are set up and configured from an NMS This is the mode Transport 331 Networks has been operated in traditionally. 333 1.3.6.2. Acronyms 335 CD MPLS-TP - Control Plane Driven MPLS-TP 337 CLI - Command Line Interface 339 EM - Element Manager 341 LCT - (correct expansion??) 343 MPLS-TD - Topology Driven MPLS 345 MPLS-TE - Traffic Engineered MPLS 347 MPLS-TP - MPLS for Transport Networks (MPLS Transport Profile) 349 ND MPLS-TP - NMS Driven MPLS-TP 351 NE - Network Element 353 NMS - Network Management System 355 TE P2MP - Traffic Engineered P2MP 357 1.3.7. MPLS Terminology structure 359 In the abbreviated table below a way of thinking about the 360 relationship between the MPLS RFCs, MPLS protocols, MPLS packages and 361 MPLS Aggregate Packages is outlined. 363 We take the approach that RFCs can be grouped into protocols, and 364 that protocols may form MPLS packages, which in turn can be grouped 365 into Aggregate Packages. 367 In talking about "MPLS RFCs" and "MPLS protocols" we do so in a wide 368 sense, i.e. RFCs and protocols that might be used in MPLS networks. 369 Most of those are developed by working groups that we listed as "MPLS 370 working groups" in RFC 4929 [RFC4929], but there are also other 371 protocols that are used and necessary in some MPLS networks, e.g. the 372 IGPs that were developed in other working groups. 374 We have added NMS Configuration and MPLS Data Plane, even though they 375 they are not "protocols" of the same flavor as the other protocols 376 MPLS Terminology Structure 377 - a strawman ontology 378 --------------------------------------------------------------------- 379 MPLS RFCs (examples) 381 RFC5036 RFC3478 RFC3479 RFC3209 RFC3477 RFC6428 382 RFC3031 383 RFC3032 RFC3033 RFC3034 RFC3035 RFC3038 RFC3107 384 RFC3209 RFC3270 RFC3473 RFC3477 RFC3478 RFC3479 385 RFC3811 RFC3812 RFC3813 RFC3814 RFC3815 RFC4023 386 RFC4090 RFC4182 RFC4201 RFC4206 RFC4220 RFC4368 387 RFC4379 RFC5420 RFC4561 RFC4781 RFC4817 RFC4875 388 RFC4950 RFC5283 RFC5330 RFC5331 RFC5332 RFC5462 389 RFC%%61 RFC5586 RFC5710 RRFC5711 RFC5712 RFC5718 390 RFC5918 RFC5919 RFC5960 RFC6178 RFC6370 RFC6372 391 RFC6374 RFC6375 RFC6378 RFC6388 RFC6424 (mLDP) 392 RFC5316 RFC5392 etc 393 RFC2328 RFC2370 394 RFC1195 RFC3784 RFC4205 395 RFC5880 RFC5884 397 (depending on how one counts the number of RFCs may vary) 399 --------------------------------------------------------------------- 400 MPLS 401 Protocols 402 +----------+----------+----------+----------+----------+ 403 | LDP | OSPF | ISIS | RSVP-TE | LSP-PING | 404 +----------+----------+----------+----------+----------+ 405 | RFC5036 | RFC2328 | RFC1195 | RFC5712 | RFC6424 | 406 +----------+----------+----------+----------+----------+ 407 | RFC6388 | | | RFC5711 | RFC4379 | 408 +----------+----------+----------+----------+----------+ 409 | RFC5919 | | | RFC5710 | | 410 +----------+----------+----------+----------+----------+ 411 | RFC5918 | | | RFC5330 | | 412 +----------+----------+----------+----------+----------+ 413 | RFC5561 | | | RFC4875 | | 414 +----------+----------+----------+----------+----------+ 415 | (mLDP) | | | RFC3209 | | 416 +----------+----------+----------+----------+----------+ 417 | etc | | | etc | | 418 +----------+----------+----------+----------+----------+ 420 +----------+----------+----------+----------+----------+ 421 | MPLS-OAM | OSPF-TE | ISIS-TE | BFD | NMS Conf | 422 +----------+----------+----------+----------+----------+ 423 | RFC6378 | RFC2370 | RFC3784 | RFC5880 | nil | 424 +----------+----------+----------+----------+----------+ 425 | RFC6375 | RFC3471 | RFC5316 | RFC5884 | | 426 +----------+----------+----------+----------+----------+ 427 | RFC6374 | RFC3473 | RFC4205 | | | 428 +----------+----------+----------+----------+----------+ 429 | RFC6372 | RFC4203 | | | | 430 +----------+----------+----------+----------+----------+ 431 | RFC6370 | | | | | 432 +----------+----------+----------+----------+----------+ 433 | RFC5586 | | | | | 434 +----------+----------+----------+----------+----------+ 435 | etc | | | | | 436 +----------+----------+----------+----------+----------+ 438 +----------+----------+----------+----------+----------+ 439 | MPLS-DP | MPLS-NM | BGP | | | 440 +----------+----------+----------+----------+----------+ 441 | RFC6178 | RFC5718 | RFC3107 | | | 442 +----------+----------+----------+----------+----------+ 443 | RFC5960 | RFC4368 | | | | 444 +----------+----------+----------+----------+----------+ 445 | RFC5462 | RFC4220 | | | | 446 +----------+----------+----------+----------+----------+ 447 | RFC4182 | RFC3815 | | | | 448 +----------+----------+----------+----------+----------+ 449 | RFC4023 | RFC3814 | | | | 450 +----------+----------+----------+----------+----------+ 451 | RFC3473 | RFC3813 | | | | 452 +----------+----------+----------+----------+----------+ 453 | etc | etc | | | | 454 +----------+----------+----------+----------+----------+ 456 --------------------------------------------------------------------- 457 MPLS Packages 459 +-----------+-----------+-----------+-----------+-----------+ 460 | MPLS-TD 1 | MPLS-TD 2 | MPLS-TD | MPLS-TD | GMPLS 1 | 461 | | | P2MP 1 | P2MP 2 | | 462 +===========+===========+===========+===========+===========+ 463 | ISIS | OSPF | ISIS | OSPF | OSPF-TE | 464 +-----------+-----------+-----------+-----------+-----------+ 465 | LDP | LDP | LDP | LDP | RSVP-TE | 466 +-----------+-----------+-----------+-----------+-----------+ 467 | | | RFC6388 | RFC6388 | | 468 | | | (mLDP) | (mLDP) | | 469 +-----------+-----------+-----------+-----------+-----------+ 471 +-----------+-----------+-----------+-----------+-----------+ 472 | MPLS-TD | | | | | 473 | BGP | | | | | 474 +===========+===========+===========+===========+===========+ 475 | BGP | | | | | 476 | RFC3107 | | | | | 477 +-----------+-----------+-----------+-----------+-----------+ 479 +-----------+-----------+-----------+-----------+-----------+ 480 | MPLS-TE 1 | MPLS-TE 2 | MPLS-TE | MPLS-TE | GMPLS 2 | 481 | | | P2MP 1 | P2MP 2 | | 482 +===========+===========+===========+===========+===========+ 483 | ISIS-TE | OSPF-TE | ISIS-TE | OSPF-TE | ISIS-TE | 484 +-----------+-----------+-----------+-----------+-----------+ 485 | RSVP-TE | RSVP-TE | RSVP-TE | RSVP-TE | RSVP-TE | 486 +-----------+-----------+-----------+-----------+-----------+ 487 | | | RFC4875 | RFC4875 | | 488 +-----------+-----------+-----------+-----------+-----------+ 490 +-----------+-----------+-----------+-----------+-----------+ 491 | MPLS-TP 1 | MPLS-T2 2 | MPLS-TP 3 | MPLS-TP 4 | MPLS-TP 5 | 492 |ND MPLS-TP |CD MPLS-TP | CD-MPLS-TP| P2MP TP | P2MP TP | 493 +===========+===========+===========+===========+===========+ 494 | NMS conf | OSPF-TE | ISIS-TE | static | OSPF-TE | 495 +-----------+-----------+-----------+-----------+-----------+ 496 | MPLSP OAM | RSVP-TE | RSVP-TE | RSVP-TE | RSVP-TE | 497 +-----------+-----------+-----------+-----------+-----------+ 498 | | MPLS OAM | MPLS OAM | MPLS OAM | MPLS OAM | 499 +-----------+-----------+-----------+-----------+-----------+ 501 --------------------------------------------------------------------- 502 MPLS Aggregate Packages 504 +--------------+--------------+--------------+ 505 | MPLS-TD | MPLS-TE | MPLS-TP | 506 | | | | 507 +==============+==============+==============+ 508 | MPLS-TD 1 | MPLS-TE 1 | MPLS-TP 1 | 509 | | | ND MPLS-TP | 510 +--------------+--------------+--------------+ 511 | MPLS-TD 2 | MPLS-TE 2 | MPLS-TP 2 | 512 | | | CD MPLS-TP | 513 +--------------+--------------+--------------+ 514 | MPLS-TD | MPLS-TE | MPLS-TP 3 | 515 | P2MP 1 | P2MP 1 | CD MPLS-TP | 516 +--------------+--------------+--------------+ 517 | MPLS-TD | MPLS-TE | MPLS-TP 4 | 518 | P2MP 2 | P2MP 2 | P2MP TP | 519 +--------------+--------------+--------------+ 520 | | GMPLS 1 | | 521 | | | | 522 +--------------+--------------+--------------+ 523 | | GMPLS 2 | | 524 | | | | 525 +--------------+--------------+--------------+ 527 --------------------------------------------------------------------- 528 MPLS Technology 530 --------------------------------------------------------------------- 531 2. Unified MPLS Requirements 533 This section list the high level requirements for Unified MPLS. 535 2.1. Full Interoperability and Interworking 537 One important aspect of Unified MPLS is to promote interoperability 538 and interworking between different flavors of MPLS. Unified MPLS 539 addresses the problem of cross-MPLS interoperation and interworking. 541 Requirement: Unified MPLS SHALL guarantee full interoperability 542 between all MPLS packages, i.e. SHALL e.g. be possible to start an 543 LSP in an MPLS-TP network, cross MPLS-TE network and terminate it in 544 a MPLS-TD network. 546 2.2. Common Data Plane 548 Requirement: The actions taken on a MPLS encapsulated packet relative 549 to the label on top of the label stack, SHALL be the same regardless 550 if the LSP has been set up using any of the MPLS routing and 551 signaling protocols or if it has been established manually or from an 552 NMS. 554 2.3. Common OAM 556 OAM is defined as part of the data plane. One goal with Unified MPLS 557 is that it shall be possible to use MPLS-TP OAM for all MPLS 558 packages. 560 Requirement: Given that MPLS-TP OAM is used there SHALL NOT, from the 561 point of view of an MPLS encapsulated packet traversing the data 562 plane of a MPLS Network, be any differences depending on whether the 563 LSP has been set up using any of the MPLS routing and signaling 564 protocols or if it has been established manually or from an NMS. 566 2.4. Data Plane Agnostic 568 Requirement: The relationship between LSPs and the payload 569 transported on those LSPs, i.e. PWs, LSPs and IP, SHALL be the same 570 regardless if the payload is transported by one or the other of the 571 MPLS packages. 573 2.5. Interworking 575 Requirement: There SHALL be no limitations in the possibilities to 576 hand over payload from one LSP to another regardless of how the LSPs 577 has been established, i.e. it SHALL be possible to carry a PW on a 578 MPLS-TP or MPLS-TD segment and then hand it over to a MPLS-TE LSP and 579 vice versa. 581 3. Unified MPLS Overview 583 This section should contain a high-level overview of Unified MPLS. 584 Here we discuss interfacing different mpls types! 586 QUESTION: Do we have to consider also co-existence of different 587 packages (e.g. CD-MPLS-TP and MPLS-TE)? Do we want to consider a 588 network being physically partitioned or logically too? 590 QUESTION: Do we want to describe the possibility of reusing tools/ 591 protocols defined into one package into other ones? 593 3.1. Unified MPLS Control Plane 595 Unified MPLS comprises a set of protocols for implementing a Control 596 Plane for Network Layer, for Routing and LSP label distribution. We 597 consider the following routing protocols: OSPF and ISIS and their 598 versions with Traffic Engineering extensions. We also consider the 599 following LSP label distribution protocols: LDP and RSVP-TE (and its 600 extensions for MPLS-TP). Each package having a control plane uses a 601 combination of them. 603 We also consider the possibility where PW level is setup and 604 maintained via tLDP. 606 One aim of Unified MPLS is to consider the Control Plane implications 607 of putting two network domains in relationship, where one or both of 608 them implements a control plane; not all the combinations may 609 interwork in principle. Further considerations are done in 610 Section 4.4. 612 3.2. Unified MPLS Data Plane 614 Unified MPLS comprises a standard MPLS data plane [RFC3031]. The 615 following information is relevant to Unified MPLS. 617 The forwarding functions comprise the mechanisms required for 618 forwarding the encapsulated native service traffic over an MPLS 619 network, for example, LSP and PW labels. 621 MPLS label switching operations and Time-to-Live (TTL) processing 622 procedures are used, as defined in [RFC3031], [RFC3032], [RFC3443] 623 and [RFC5921]. 625 SS-PW and MS-PW forwarding operations are used, as defined in 626 [RFC3985] and [RFC5659]. 628 Per-platform label space is used for PWs. Either per-platform, per- 629 interface, or other context-specific label space [RFC5331] may be 630 used for LSPs. 632 MPLS forwarding is based on the label that identifies the path (LSP 633 or PW). The label value specifies the processing operation to be 634 performed by the next hop at that level of encapsulation. A swap of 635 this label is an atomic operation in which the contents of the packet 636 after the swapped label are opaque to the forwarder. The only event 637 that interrupts a swap operation is TTL expiry. TTL expiry, which is 638 a fundamental architectural construct of MPLS to be taken into 639 account when designing protocol extensions (such as those for OAM) 640 that require packets to be sent to an intermediate LSR. 642 Further processing to determine the context of a packet occurs when a 643 swap operation is interrupted in this manner, or a pop operation 644 exposes a specific reserved label at the top of the stack (including 645 the GAL). Otherwise, the packet is forwarded according to the 646 procedures in [RFC3032]. 648 MPLS Differentiated Services (Diffserv) architecture [RFC3270] is the 649 suggested mode of supporting Quality of Services in Unified MPLS. 650 Both E-LSP and L-LSP MPLS Diffserv modes are supported. 652 Multicast MPLS is left for further study within Unified MPLS. 654 3.3. Unified MPLS Management 656 Here we want to describe the possible methods for Management of 657 Unified MPLS. Commonly used methods, such as CLI, may be used in 658 conjunction with LCT, EM, NMS, as described in [RFC5950]. Most 659 important functions related to Management are: provisioning of 660 network layer and service layer, fault and performance monitoring, 661 inventory. 663 In several profiles of MPLS, provisioning of network layer and 664 service layer is done by means of Control Plane. Where Management 665 plane only is used for provisioning (e.g. in ND-MPLS-TP), routing, 666 Path Computation Element, label distribution, configuration of the 667 parameters for network and service layer are done via network 668 management tools. 670 Where several subnetworks are deployed, it may happen that only a 671 subset of them is operated via Management, while another is operated 672 via Control Plane. The dependencies of the two has to be analysed. 674 3.4. Unified MPLS OAM 676 OAM is used to perform functions of operation, administration and 677 maintenance (a comprehensive description of OAM functions is 678 described in [RFC6291]). These functions are applicable both to LSP 679 and PW. Among all the functions provided by OAM, fault management 680 and performance monitoring are used to have a common method to verify 681 the behavior of a network domain and a single mean to monitor the 682 different kinds of service being provided. 684 OAM for MPLS has been defined in [LIST-OF-RFC-OF-OAM-FOR-LSP], 685 especially because of the requirements of MPLS-TP. OAM for PW has 686 been defined in [LIST-OF-RFC-OF-OAM-FOR-PW]. 688 One critical objective of Unified MPLS is to describe how these tools 689 can be used in a multi-domain MPLS network, where different packages 690 can be deployed. 692 4. Interfaces and Interworking 694 Where two or more subnetworks (or profiles instances) are deployed 695 within an operator network, it is important to consider the interface 696 between each pair of them. Peering relationship is where the two 697 subnetworks are at the same level with respect to the end-to-end 698 service being provided. Peering relationship may happen at LSP, PW 699 or client service level. Overlay relationship is where one 700 subnetwork is client of the other one, so that the server subnetwork 701 provides connectivity to part of the client one. In this section we 702 discuss the most important interfaces and subnetwork interworking. 704 4.1. Interfaces 706 Several packages are considered within MPLS Technology. Anyhow there 707 is not yet a guideline on how to use a combination of different 708 packages in a single operator network. With Unified MPLS we want to 709 describe the interfaces between the different packages. The number 710 of the possible interfaces is quite high, so a brute force approach 711 for their description is not beneficial to the reader. An objective 712 of Unified MPLS is to start the analysis with the most common 713 interworking scenarios. 715 The interface between two domains may be a node or a link. The two 716 cases may lead to different requirements and behaviors at the 717 interface. It may happen that one or several interfaces (of the same 718 kind) happen between two domains. 720 4.2. Network Layer Interworking 722 This document uses the term Network Layer in the same sense as it is 723 used in [RFC3031] and [RFC3032]. 725 Two peering network domains (each one implementing one instance of 726 any MPLS package) interwork at Network Layer when they are configured 727 to interconnect at LSP or PW level. LSP stitching and MS-PW are 728 used, depending on the level chosen. LSP stitching may be used for 729 any client signal encapsulated into the end-to-end LSP (MPLS, PW, 730 IP), while MS-PW can only be used for PW encapsulated signals. 732 4.3. Service Layer Interworking 734 Service interface (UNI and NNI) reference models are described in 735 [RFC5921] and further analyzed in [RFC6125]. 737 Two peering network domains (each one implementing one instance of 738 any MPLS package) interwork at Service Layer when they are configured 739 to interconnect at client service level. In case of border link 740 interconnecting the two domains, it can be named UNI in [RFC6125] 741 terminology. 743 In case of border node interconnecting the two domains, Termination 744 mode applies. 746 4.4. Network Overlay 748 When two network domains are in Overlay relationship, in principle 749 there isn't any interworking between them. Anyhow there are few 750 aspects to be taken into account, at least from CP and Fault 751 Management point of view. 753 CP aspects has to be considered when the client network domain is CD 754 (it implements a CP). If the server network domain is CD, there is 755 the possibility to interact between the two CPs. if the server 756 network is ND, then the resources for the client domain must be pre- 757 allocated. 759 In case OAM tool set is used in both client and server network 760 domain, there is the possibility to propagate fault indication, 761 happened within the server domain, into the client domain. 763 One Unified MPLS aim is also to specific constraints given by the 764 used packages (E.g. if a domain using MPLS-TE is client of a domain 765 using MPLS-TD, bandwidth requirements of the client layer may not be 766 guaranteed. 768 5. MPLS Resiliency 770 This section will dicuss different aspects of MPLS resiliency, like 771 protection, suvivability and recovery. 773 5.1. MPLS Recovery 775 Note: Text needed! 777 5.2. MPLS Protection 779 Note: Text needed! 781 5.3. MPLS Survivability 783 Note: Text needed! 785 6. Other Unified MPLS Considerations 787 It is quite possible that Unified MPLS should also address a number 788 of other aspects of MPLS. 790 7. Security Considerations 792 Security considerations to be added. 794 8. IANA considerations 796 There are no IANA considerations for this document (at least 797 currently) an IANA section will be added as necessary. 799 9. Acknowledgments 801 We have recieved valuable feeback from several people working with 802 adapting and utilizing MPLS in their networks. 804 10. References 806 10.1. Normative References 808 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 809 Requirement Levels", BCP 14, RFC 2119, March 1997. 811 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 812 November 1998. 814 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 815 Label Switching Architecture", RFC 3031, January 2001. 817 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 818 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 819 Encoding", RFC 3032, January 2001. 821 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 822 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 823 Tunnels", RFC 3209, December 2001. 825 [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for 826 Multiprotocol Label Switching Architecture (MPLS) 827 Operation and Maintenance (OAM) Functions", RFC 3429, 828 November 2002. 830 [RFC4929] Andersson, L. and A. Farrel, "Change Process for 831 Multiprotocol Label Switching (MPLS) and Generalized MPLS 832 (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, 833 June 2007. 835 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 836 Associated Channel", RFC 5586, June 2009. 838 10.2. Informative references 840 [I-D.bryant-mpls-tp-jwt-report] 841 Bryant, S. and L. Andersson, "JWT Report on MPLS 842 Architectural Considerations for a Transport Profile", 843 draft-bryant-mpls-tp-jwt-report-00 (work in progress), 844 July 2008. 846 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 847 Berger, "A Framework for MPLS in Transport Networks", 848 RFC 5921, July 2010. 850 Authors' Addresses 852 Loa Andersson 853 Ericsson 855 Email: loa@pi.nu 857 Riccardo Martinotti 858 Ericsson 860 Email: riccardo.martinotti@ericsson.com