idnits 2.17.1 draft-allan-mpls-unified-ic-req-frmwk-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 2012) is 4417 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) -- Obsolete informational reference (is this intentional?): RFC 4379 (ref. '3') (Obsoleted by RFC 8029) == Outdated reference: A later version (-05) exists of draft-ietf-l2vpn-vpms-frmwk-requirements-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Dave Allan, Ed. 2 Internet Draft Ericsson 3 Intended status: Standards Track 4 Expires: September 2012 March 2012 6 Requirements and Framework for Unified MPLS Sub-Network 7 Interconnection 9 draft-allan-mpls-unified-ic-req-frmwk-01 11 Abstract 13 The definition of a transport profile for MPLS means that MPLS 14 network architectures will emerge that combines both managed and 15 control plane driven MPLS sub-networks and requires interconnection 16 of same to achieve a unified MPLS architecture. 18 This document generalizes the problem of sub-network interconnect, 19 discusses issues in general and suggests ways forward. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC2119 [1]. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance 30 with the provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet 33 Engineering Task Force (IETF), its areas, and its working 34 groups. Note that other groups may also distribute working 35 documents as Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other 39 documents at any time. It is inappropriate to use Internet- 40 Drafts as reference material or to cite them other than as "work 41 in progress". 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire in September 2012. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with 61 respect to this document. Code Components extracted from this 62 document must include Simplified BSD License text as described 63 in Section 4.e of the Trust Legal Provisions and are provided 64 without warranty as described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction...................................................3 69 2. Conventions used in this document..............................4 70 2.1. Terminology..................................................4 71 2.2. Acronyms.....................................................4 72 3. Sub-Network Interconnect Scenarios.............................4 73 4. Sub-Network Interconnect Mechanisms............................5 74 4.1. Border Node..................................................5 75 4.2. Border Link..................................................5 76 5. Sub-network types..............................................5 77 5.1. Infrastructure sub-network types.............................5 78 5.2. Service Sub-network types....................................6 79 6. Issues & Requirements..........................................6 80 6.1. Alignment of OAM functionality...............................7 81 6.2. OAM identifier mismatches....................................7 82 6.3. OAM encapsulation............................................7 83 6.4. Protection Mechanisms........................................8 84 6.5. Label space management.......................................8 85 6.6. Path maintenance and re-sizing...............................8 86 6.7. Sub-network migration........................................9 87 6.8. (Non)Interworking of DP and CP notifications.................9 88 7. Operational Decoupling.........................................9 89 8. Acknowledgments...............................................10 90 9. IANA Considerations...........................................10 91 10. Security Considerations......................................10 92 11. References...................................................10 93 11.1. Informative References.....................................10 95 1. Introduction 97 Networks that provide an end-to-end service infrastructure are 98 typically deployed as multiple domains or sub-networks in order to 99 scale. These different domains may be operated by different 100 technologies using different control plane technology (e.g. 101 management driven control plane (centralized) or distributed control 102 plane). 104 Within the MPLS control plane there exist a number of functional 105 behaviors that are typically associated with a single control 106 protocol and function autonomously from the other control protocols. 107 That is to say when a labeled layer and associated control protocol 108 is overlaid on another, there is frequently no operational coupling 109 between them. When two control protocols are operated side by side 110 the same is true (e.g. ships in the night). An example of the former 111 would be pseudo wires over a PSN. An example of the latter would be 112 L2 and L3 virtual private networks (VPNs) sharing a common packet 113 switched network (PSN). 115 The introduction of transport functions to MPLS and the intent to 116 deploy, merge or otherwise combine networks that will concatenate 117 sub-networks that have different operational characteristics and/or 118 control planes (including management) introduces the requirement to 119 integrate operations across multiple sub-networks. This frequently is 120 manifested in requirements on nodes at sub-network boundaries and/or 121 alignment of identifiers in order to construct a unified end-to-end 122 MPLS based service plane. 124 By having a unified MPLS based service plane, a network operator is 125 able to provide services across different MPLS domains instrumented 126 with common management and control functionality in order to provide 127 scalable service offerings on a common MPLS technology base. 129 This document is a framework that postulates models and functional 130 requirements for sub-network interconnect to achieve a unified end to 131 end MPLS based service plane or "Unified MPLS". 133 2. Conventions used in this document 135 2.1. Terminology 137 Binding: Is the mechanism for association and interconnection of 138 label switched path (LSP) or pseudo wire (PW) segments that exist in 139 different sub-networks. 141 Section: As per RFC 5960[17]. 143 Segment: A part of a PW or LSP that has one or more contiguous 144 sections in a common sub-network. This usage is as per RFC 6372[18]. 146 Sub-network: A portion of a larger MPLS network that is operated by a 147 single system and whose boundaries are set by the scope of the 148 system. The system may be a control plane or management system. 149 Similarly it could be a sub-layer stacked on another sub-network. 151 2.2. Acronyms 153 LIB - label information base 155 LSP - label switched path 157 MEG - Maintenance Entity Group 159 MEP - Maintenance Entity Group End Point 161 MIP - Maintenance Entity Group Intermediate Point 163 PSN - packet switched network 165 PW - pseudo wire 167 SPME - Sub-path Maintenance Entity 169 VPWS - Virtual Private Wire Service 171 VPMS - Virtual Private Multicast Service 173 3. Sub-Network Interconnect Scenarios 175 The combination of MPLS label swapping and label stacking makes it 176 possible to consider a number of atomic interconnect scenarios, 177 briefly summarized here: 179 Peer Model - is the scenario when an LSP or PW has segments in 180 different sub-networks. 182 Segmentation Model - is the scenario when a client LSP or PW with 183 common establishment and maintenance procedures has sections in 184 separate sub-networks. This model can recurse arbitrarily. 186 Overlay Model - is the simplest case of the segmentation model in 187 which a section of an LSP or PW is a distinct sub-network. This is 188 currently the common deployment scenario for MPLS, and normally has 189 minimal dependencies. In the specific case of MPLS & GMPLS, the 190 requirements are examined in RFC 5146[21]. 192 Termination Model - is the scenario where a non-MPLS or PW transfer 193 function separates the sub-networks. The termination model logically 194 isolates the sub-networks and is included simply for completeness. 196 4. Sub-Network Interconnect Mechanisms 198 There are two interconnect mechanisms considered. The first (Border 199 node) postulates a node that spans two sub-networks and both likely 200 operated by a single provider. The second (Border link) postulates a 201 link connecting sub-networks of two distinct organizations within a 202 provider or two distinct providers. 204 4.1. Border Node 206 A border node is one that implements, interconnects and interworks 207 LSPs or PWs with segments or sections in different sub-networks. The 208 interworking function at the border node will either terminate, swap 209 or encapsulate labels. 211 4.2. Border Link 213 A border link is the case whereby two border nodes are connected back 214 to back in an MPLS sub-network that consists of a single link. This 215 can be a physical link or a logical link (e.g. an MPLS section). 217 5. Sub-network types 219 In the current MPLS architecture the following sub-network types 220 exist: 222 5.1. Infrastructure sub-network types 224 The infrastructure sub-network types are: 226 MPLS-TD: Topology driven MPLS. LSP setup is via the LDP protocol [6] 227 with path routing determined by the IGP. ECMP, merging and PHP are 228 are included in the set of possible dataplane behaviors. LSPs are 229 unidirectional only. P2mp and mp2mp LSPs are supported by mLDP [7]. 231 MPLS-TE: LSP setup is via the RSVP-TE protocol[8] with path routing 232 determined by a TE enabled IGP (e.g. OSPF-TE) according to bandwidth 233 and QoS constraints. PHP is included in the set of dataplane 234 behaviors. LSPs are unidirectional only. Bandwidth allocations, class 235 of service or priority(PHB) are typically part of traffic handling. 237 Managed MPLS-TP: LSP setup is via management action. LSPs can be uni- 238 directional, bi-directional or associated bi-directional. LSPs are 239 purely connection oriented p2p or p2mp (where p2mp is unidirectional 240 only). 242 Signalled MPLS-TP: LSP setup is via RSVP-TE GMPLS[9]. LSPs can be 243 uni-directional, bi-directional or associated bi-directional. LSPs 244 are purely connection oriented p2p or p2mp (where p2mp is 245 unidirectional only). 247 And it is possible to consider 249 GMPLS for non-MPLS dataplanes: 251 5.2. Service Sub-network types 253 L3VPN: VPN setup is via the BGP protocol as per RFC 4364[10]. Note 254 that this can be an IP-VPN (via IGP peering with the VRF) or an MPLS- 255 VPN (via a combination of IGP and MPLS CP peering with the VRF). 257 L2VPN: VPN setup is via the PW Control Protocol per RFC 4447 (LDP in 258 targeted mode) or BGP protocols. A broadcast domain is emulated which 259 will have the effect of limiting sub-network interconnect to a single 260 point to avoid loops. 262 VPWS: VPWS setup is via the PW Control Protocol per RFC 4447 (LDP in 263 targeted mode). 265 VPMS: VPMS setup is currently an L2VPN work item . 266 [20]. 268 6. Issues & Requirements 270 In theory, any ingress label can be mapped to one or more egress 271 labels or label stack permutations via the ILM to NHLFE mapping 272 defined in RFC 3031[2]. Further one carrier"s infrastructure layer 273 may be a client of another carrier"s infrastructure. More 274 considerations need to come into play in order to produce a tractable 275 set of sub-network interworking scenarios. The following is a partial 276 list of some of the issues to be considered and/or addressed: 278 6.1. Alignment of OAM functionality 280 Not all OAM encapsulations guarantee fate sharing with the LSP of 281 interest across all of the sub-network types in MPLS. This not only 282 means that failures may not be detected or detected in a timely 283 manner, it also means that "false positives" are a possibility as 284 failures may occur on the path taken by the OAM PDUs. 286 Any OAM encapsulation using a reserved label, e.g. the GAL[12], or 287 Router Alert as used by VCCV type 2[13], or without a PW control word 288 will not have predictable control over fate sharing with normal 289 payload for any LSP or PW that has a section that transits a MPLS-TD 290 sub network that implements ECMP[11]. Specifying that ECMP 291 implementations exclude reserved labels from consideration would 292 permit ECMP and LAG approaches that limit the sources of entropy to 293 the label stack (e.g. FAT PWs [ref] or the entropy label [ref]) to be 294 employed and be correctly and reliably instrumented by OAM that used 295 a reserved label. 297 A separate issue is interconnecting sub networks where the LSPs have 298 a different cardinality of end points (e.g. concatenating mp2p to 299 p2p), implying a different number of maintenance entities than would 300 be suggested by an implementation dimensioned to a single sub 301 network"s characteristics. 303 6.2. OAM identifier mismatches 305 MEG, MEP, MIP and nodal addressing will not pose identifier mismatch 306 problems. Where such problems will arise is in the use of RFC 4379 307 LSP Ping [3]. This is because LSP-PING uses identifiers associated 308 with a specific sub-network type in the FEC stack as part of the 309 processing to detect inconsistencies between the control plane and 310 the data plane. 312 [Issue: The on demand CV draft provides for the Static LSP and Static 313 PW TLVs for the FEC stack which allows intermediate nodes to validate 314 the FEC stack against the MEG ID for the local MIP. The applicability 315 for this should be generalized such that it can be used end to end 316 across domains. This will also raise the problem of disseminating MEG 317 information to non-transport sub networks as not all defined MPLS 318 sub-network types use the current fields in the IP based LSP MEG ID] 320 6.3. OAM encapsulation 322 The MPLS architecture permits multiple OAM encapsulations that may or 323 may nor have an IP header. Any interconnect mechanism needs to be 324 able to align not only capability but encapsulations end to end. This 325 document assumes that translation of encapsulations by MIPs will not 326 be specified or implemented. 328 6.4. Protection Mechanisms 330 An MPLS LSP or PW sub-network may be made resilient by any number of 331 mechanisms. There are also three scenarios of note, end to end 332 protection, end to end restoration and sub-network protection. 334 End to end protection offers minimal complications in sub-network 335 interconnect as the interworking functions is common to that of the 336 unprotected case, that is to say transit nodes do not participate in 337 protection switching. 339 Sub-network protection is universally offered by the use of 340 mechanisms that operate within the level such as detours [19] and may 341 require label merging at the border node. Mechanisms that operate at 342 nested MPLS label levels (e.g. SPMEs or FRR facility protection) have 343 no impact on sub-network interconnect. 345 End to end restoration is a bit more complicated as it involves 346 coordinating dynamic action between sub-networks. 348 It also becomes possible to consider sub-network restoration with 349 many of the same considerations as path maintenance and re-sizing. 351 6.5. Label space management 353 The MPLS architecture has always been based around local 354 administration of a node"s label space. As such mechanisms to 355 partition the label space between multiple administrative entities is 356 not currently supported and would be difficult to retrofit. 358 A consequence of this is that a border node is potentially required 359 to provide labels from a common pool to both a control and management 360 plane, e.g. a management system be required to obtain label values 361 from the node prior to populating the LIB vs. being delegated a pool. 362 This suggests that such a mechanism be carried forward for all 363 managed nodes such that only a single mechanism need be implemented. 364 However this is an implementation decision. 366 6.6. Path maintenance and re-sizing 368 It must be possible to make operational modifications to a path 369 segment in a hitless fashion. The normal procedure for MPLS-TE is 370 known as "make before break". This gives rise to two scenarios, the 371 first is end to end "make before break", and the other is make before 372 break confined to a sub-network with the border node as a pinned 373 waypoint. This means the design of the inter-sub-network binding 374 information permit make before break modification of one segment of 375 the LSP. 377 6.7. Sub-network migration 379 The practical considerations are documented in RFC 5950[4] and by 380 reference RFC 5493[5]. 382 6.8. (Non)Interworking of DP and CP notifications 384 Within the MPLS architecture there are techniques for propagating the 385 status of adjacent sections of either a native service or PW section 386 in both the data plane and the control plane. One example 387 (documenting both) is RFC 6310[14]. 389 When concatenating sub networks the interworking of dataplane fault 390 notifications [15] or protection switching coordination [16] and 391 control plane indications will not be possible. The reason is that 392 data plane indications flow end to end on a labeled path therefore 393 will not be visible to border nodes, a requirement to enable 394 interworking of dataplane notifications with the control plane in any 395 useful form. 397 When connecting a sub network restricted to data plane only 398 notifications to a sub network that will support either dataplane or 399 control plane notifications, the border node will be required to 400 negotiate exclusive use of dataplane notifications in any control 401 plane signaling during the path setup. This will have implications in 402 both the interconnect data model, and potential enhancements to 403 signaling. 405 7. Operational Decoupling 407 The objective of any sub-network interconnect solution is to decouple 408 the operation of the interconnected systems in order to minimize any 409 dependencies. 411 The sub-network interconnect must accommodate interconnecting LSPs 412 and PWs with different establishment and persistency characteristics. 413 This is determined by whether the LSP, PW or segment is provisioned 414 or signaled, where from a persistency point of view, a provisioned 415 entry is permanent and exists until removed by management action, 416 while a signaled entity fate shares with a control plane adjacency 417 and may come and go during the life time of the inter sub-network 418 binding. 420 The state present at a border node to bind the LSP or PW spanning the 421 sub networks together should exist independently of the 422 characteristics of the LSPs or associated control or management 423 planes. 425 This also requires a level of indirection such that the management 426 action is decoupled from the mechanics of label assignment in each 427 sub-network and may work with sub-network resiliency mechanisms. 429 So the state "connect whatever label from sub-network A associated 430 with FOO to whatever label from sub-network B is associated with BAR" 431 should be persistent. 433 8. Acknowledgments 435 Loa Andersson, Mach Chen, Eric Gray, David Sinicrope and Greg Mirsky 436 contributed to the development of this document. 438 9. IANA Considerations 440 This document does not require IANA action. 442 10. Security Considerations 444 Sub-network interconnect in a single provider scenario does not 445 introduce any new security exposures to the MPLS architecture that do 446 not already exist. 448 Sub-network interconnect in a multi-provider scenario (e.g. border 449 link) introduces a number of potential exposures, and requires a 450 strong trust model for the co-ordination of the set up if interdomain 451 LSPs. This is particularly true for the peer model. This is somewhat 452 mitigated when operational decoupling techniques are employed as 453 discussed in section 7, as the scope of what a provider can ask of a 454 peer network is explicitly scoped. 456 11. References 458 11.1. Informative References 460 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 461 Levels", BCP 14, RFC 2119, March 1997. 463 [2] Rosen et.al. Multiprotocol Label Switching Architecture, IETF 464 RFC 3031, January 2001 466 [3] Kompella et.al. Detecting Multi-Protocol Label Switched (MPLS) 467 Data Plane Failures, IETF RFC 4379, February 2006 469 [4] Mansfield et. al. Network Management Framework for MPLS-based 470 Transport Networks, IETF RFC 5950, September 2010 472 [5] Caviglia, D., Bramanti, D., Li, D., and D. McDysan, 473 "Requirements for the Conversion between Permanent Connections and 474 Switched Connections in a Generalized Multiprotocol Label 475 Switching (GMPLS) Network", RFC 5493, April 2009. 477 [6] Andersson et.al. "LDP Specification", IETF RFC 5036, October 478 2007 480 [7] Minei, I. et.al. "Label Distribution Protocol Extensions for 481 Point-to-Multipoint and Multipoint-to-Multipoint Label Switched 482 Paths", IETF RFC 6388 484 [8] Awduche et.al. "RSVP-TE: Extensions to RSVP for LSP Tunnels", 485 IETF RFC 3209, December 2001 487 [9] Berger et.al. "Generalized Multi-Protocol Label Switching 488 (GMPLS) Signaling Functional Description", IETF RFC 3471, January 489 2003 491 [10] Rosen et.al. "BGP/MPLS IP Virtual Private Networks (VPNs)", 492 IETF RFC 4364, February 2006 494 [11] Swallow et.al. "Avoiding Equal Cost Multipath Treatment in MPLS 495 Networks", IETF RFC 4928, June 2007 497 [12] Bocci et.al. "MPLS Generic Associated Channel", IETF RFC 5586, 498 June 2009 500 [13] Nadeau et.al "Pseudowire Virtual Circuit Connectivity 501 Verification (VCCV) A Control Channel for Pseudowires", IETF RFC 502 5085, December 2007 504 [14] Aissaoui et.al. "Pseudowire (PW) Operations, Administration, 505 and Maintenance (OAM) Message Mapping", IETF RFC 6310, July 2011 507 [15] Swallow et.al. "MPLS Fault Management OAM", IETF RFC 6427, 508 November 2011 510 [16] Bryant et.al. "MPLS-TP Linear Protection", IETF RFC 6378, 511 October 2011 513 [17] Frost et.al. "MPLS Transport Profile Data Plane Architecture", 514 IETF RFC 5960, August 2010 516 [18] Sprecher et.al. "MPLS Transport Profile (MPLS-TP) Survivability 517 Framework", IETF RFC 6372, September 2011 519 [19] Pan et.al. "Fast Reroute Extensions to RSVP-TE for LSP 520 Tunnels", IETF RFC 4090, May 2005 522 [20] Kamite et.al., "Framework and Requirements for Virtual Private 523 Multicast Service (VPMS)", IETF work in progress, draft-ietf- 524 l2vpn-vpms-frmwk-requirements-04.txt, July 2011 526 [21] Kumaki et.al., Interworking Requirements to Support Operation 527 of MPLS-TE over GMPLS Networks, IETF RFC 5146, March 2008 529 Authors' Addresses 531 Dave Allan 532 Ericsson 533 Email: david.i.allan@ericsson.com