idnits 2.17.1 draft-ietf-mpls-tp-gach-gal-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC4385, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3032, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5085, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3032, updated by this document, for RFC5378 checks: 1997-11-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 21, 2009) is 5453 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) -- Looks like a reference, but probably isn't: 'RFC4385' on line 714 ** Obsolete normative reference: RFC 5226 (ref. '9') (Obsoleted by RFC 8126) == Outdated reference: A later version (-12) exists of draft-ietf-mpls-tp-framework-00 -- Obsolete informational reference (is this intentional?): RFC 4379 (ref. '13') (Obsoleted by RFC 8029) == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-vccv-bfd-04 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-oam-requirements-01 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-tp-requirements-08 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group M. Bocci, Ed. 3 Internet-Draft M. Vigoureux, Ed. 4 Updates: 3032, 4385, 5085 Alcatel-Lucent 5 (if approved) S. Bryant 6 Intended status: Standards Track Cisco 7 Expires: November 22, 2009 9 May 21, 2009 11 MPLS Generic Associated Channel 12 draft-ietf-mpls-tp-gach-gal-06 14 Status of this Memo 16 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 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 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on November 22, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document generalizes the applicability of the pseudowire (PW) 51 Associated Channel Header (ACH), enabling the realization of a 52 control channel associated to MPLS Label Switched Paths (LSPs) and 53 MPLS Sections in addition to MPLS pseudowires. In order to identify 54 the presence of this Associated Channel Header in the label stack, 55 this document also assigns one of the reserved MPLS label values to 56 the Generic Associated Channel Label (GAL), to be used as a label 57 based exception mechanism. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.3. Requirements Language and Terminology . . . . . . . . . . 5 65 2. Generic Associated Channel Header . . . . . . . . . . . . . . 5 66 2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.2. Allocation of Channel Types . . . . . . . . . . . . . . . 6 68 3. ACH TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.1. ACH TLV Payload Structure . . . . . . . . . . . . . . . . 7 70 3.2. ACH TLV Header . . . . . . . . . . . . . . . . . . . . . . 8 71 3.3. ACH TLV Object . . . . . . . . . . . . . . . . . . . . . . 8 72 4. Generalized Exception Mechanism . . . . . . . . . . . . . . . 9 73 4.1. Relationship with Existing MPLS OAM Alert Mechanisms . . . 9 74 4.2. GAL Applicability and Usage . . . . . . . . . . . . . . . 10 75 4.2.1. GAL Processing . . . . . . . . . . . . . . . . . . . . 10 76 4.3. Relationship with RFC 3429 . . . . . . . . . . . . . . . . 13 77 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14 78 6. Congestion Considerations . . . . . . . . . . . . . . . . . . 15 79 7. Major Contributing Authors . . . . . . . . . . . . . . . . . . 15 80 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 88 1. Introduction 90 There is a need for Operations, Administration and Maintenance (OAM) 91 mechanisms that can be used for fault detection, diagnostics, 92 maintenance and other functions on a pseudowire (PW) and a Label 93 Switched Path (LSP). These functions can be used between any two 94 Label Edge Routers (LERs) / Label Switching Router (LSRs) or 95 Terminating Provider Edge routers (T-PEs) / Switching Provider Edge 96 routers (S-PEs) along the path of an LSP or PW respectively [11]. 97 Some of these functions can be supported using existing tools such as 98 Virtual Circuit Connectivity Verification (VCCV) [1], Bidirectional 99 Forwarding Detection for MPLS LSPs (BFD-MPLS) [12], LSP-Ping [13], or 100 BFD-VCCV [14]. However, a requirement has been indicated to augment 101 this set of maintenance functions, in particular when MPLS networks 102 are used for packet transport services and transport network 103 operations [15]. Examples of these functions include performance 104 monitoring, automatic protection switching, and support for 105 management and signaling communication channels. These tools MUST be 106 applicable to, and function in essentially the same manner (from an 107 operational point of view) on MPLS PWs, MPLS LSPs and MPLS Sections. 108 They MUST also operate in-band on the PW or LSP such that they do not 109 depend on Packet Switched Network (PSN) routing or on user traffic, 110 and MUST also NOT depend on dynamic control plane functions. 112 VCCV [1] can use an Associated Channel Header (ACH) to provide a PW 113 associated control channel between a PW's end points, over which OAM 114 and other control messages can be exchanged. This document 115 generalizes the applicability of the ACH to enable the same 116 associated control channel mechanism to be used for Sections, LSPs 117 and PWs. The associated control channel thus generalized is known as 118 the Generic Associated Channel (G-ACh). The ACH, specified in RFC 119 4385 [2], may be used with additional code points to support 120 additional MPLS maintenance functions on the G-ACh. 122 Generalizing the applicability of the ACH to LSPs and Sections also 123 requires a method to identify that a packet contains an ACH followed 124 by a non-service payload. Therefore, this document also defines a 125 label based exception mechanism that serves to inform an LSR (or LER) 126 that a packet it receives on an LSP or Section belongs to an 127 associated control channel. The label used for that purpose is one 128 of the MPLS reserved labels and is referred to as the GAL (G-ACh 129 Label). The GAL mechanism is defined to work together with the ACH 130 for LSPs and MPLS Sections. 132 RFC 4379 [13] and BFD-MPLS [12] define alert mechanisms that enable 133 an MPLS LSR to identify and process MPLS OAM packets when these are 134 encapsulated in an IP header. These alert mechanisms are based, for 135 example, on Time To Live (TTL) expiration and/or on the use of an IP 136 destination address in the range of 127.0.0.0/8 or 0:0:0:0:0:FFFF: 137 127.0.0.0/104, respectively for IPv4 and IPv6. These mechanisms are 138 the default mechanisms for identifying MPLS OAM packets when 139 encapsulated in an IP header. However it may not always be possible 140 to use these mechanisms in some MPLS applications e.g., MPLS 141 Transport Profile (MPLS-TP) [11], particularly when IP based 142 demultiplexing cannot be used. This document defines a mechanism 143 that is RECOMMENDED for identifying and encapsulating MPLS OAM and 144 other maintenance messages when IP based mechanisms such as those 145 used in [13] and [12] are not available. Yet, this mechanism MAY be 146 used in addition to IP-based mechanisms. 148 Note that, in this document, maintenance functions and packets should 149 be understood in the broad sense. That is, a set of maintenance and 150 management mechanisms that include OAM, Automatic Protection 151 Switching (APS), Signaling Communication Channel (SCC) and Management 152 Communication Channel (MCC) messages. 154 Also note that the GAL and ACH are applicable to MPLS and PWs in 155 general. This document specifies general mechanism and uses MPLS-TP 156 as an example application. The application of the GAL and ACH to 157 other specific MPLS uses is outside the scope of this document. 159 1.1. Objectives 161 This document defines a mechanism that provides a solution to the 162 extended maintenance needs of emerging applications for MPLS. It 163 creates a generic control channel mechanism that may be applied to 164 MPLS LSPs and Sections, while maintaining compatibility with the PW 165 associated channel. It also normalizes the use of the ACH for PWs in 166 a transport context, and defines a label based exception mechanism to 167 alert LERs/LSRs of the presence of an ACH after the bottom of the 168 label stack. 170 1.2. Scope 172 This document defines the encapsulation header for Sections, LSPs, 173 and PWs associated control channel messages. 175 It does not define how associated control channel capabilities are 176 signaled or negotiated between LERs/LSRs or PEs, or the operation of 177 various OAM functions. 179 This document does not deprecate existing MPLS and PW OAM mechanisms. 181 1.3. Requirements Language and Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC 2119 [3]. 187 This document uses the following additional terminology: 189 ACH: Associated Channel Header 191 G-ACh: Generic Associated Channel 193 GAL: G-ACh Label 195 G-ACh packet: Any packet containing a message belonging to a protocol 196 that is carried on a PW, LSP or MPLS Section associated control 197 channel. Examples include maintenance protocols such as OAM 198 functions, signaling communications or management communications. 200 The terms 'Section' and 'Concatenated Segment' are defined in [16] as 201 follows (note that the terms 'Section' and 'Section Layer Network' 202 are synonymous): 204 Concatenated Segment: A serial-compound link connection as defined in 205 [17]. A concatenated segment is a contiguous part of an LSP or 206 multi-segment PW that comprises a set of segments and their 207 interconnecting nodes in sequence. 209 Section Layer Network: A section layer is a server layer (which may 210 be MPLS-TP or a different technology) which provides for the transfer 211 of the section layer client information between adjacent nodes in the 212 transport path layer or transport service layer. Note that G.805 213 [17] defines the section layer as one of the two layer networks in a 214 transmission media layer network. The other layer network is the 215 physical media layer network. 217 2. Generic Associated Channel Header 219 VCCV [1] defines three Control Channel (CC) Types that may be used to 220 exchange OAM messages through a PW: CC Type 1 uses an ACH and is 221 referred to as "In-band VCCV"; CC Type 2 uses the MPLS Router Alert 222 Label to indicate VCCV packets and is referred to as "Out of Band 223 VCCV"; CC Type 3 uses the TTL to force the packet to be processed by 224 the targeted router control plane and is referred to as "MPLS PW 225 Label with TTL == 1". 227 2.1. Definition 229 The use of the ACH, previously limited to PWs, is here generalized to 230 also apply to LSPs and to Sections. Note that for PWs, the PWE3 231 control word [2] MUST be present in the encapsulation of user packets 232 when the ACH is used to realize the associated control channel. 234 The ACH used by CC Type 1 is depicted in figure below: 236 0 1 2 3 237 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 |0 0 0 1|Version| Reserved | Channel Type | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 1: Associated Channel Header 244 In the above figure, the first nibble is set to 0001b to indicate a 245 control channel associated with a PW, an LSP or a Section. The 246 Version field is set to 0, as specified in RFC 4385 [2]. Bits 8 to 247 15 of the ACH are reserved and MUST be set to 0 and ignored on 248 reception. Bits 16 to 31 are used to encode the possible Channel 249 Types. This 16 bit field is in network byte order. 251 Note that VCCV [1] also includes mechanisms for negotiating the 252 Control Channel and Connectivity Verification (i.e., OAM function) 253 Types between PEs. It is anticipated that similar mechanisms will be 254 applied to LSPs. Such application will require further 255 specification. However, such specification is beyond the scope of 256 this document. 258 The G-ACh MUST NOT be used to transport user traffic. 260 2.2. Allocation of Channel Types 262 The Channel Type field indicates the type of message carried on the 263 associated control channel e.g., IPv4 or IPv6 if IP demultiplexing is 264 used for messages sent on the associated control channel, or OAM or 265 other maintenance function if IP demultiplexing is not used. For 266 associated control channel packets where IP is not used as the 267 multiplexer, the Channel Type indicates the specific protocol carried 268 in the associated control channel. 270 Values for the Channel Type field currently used for VCCV are 271 specified elsewhere e.g., in RFC 4446 [4] and RFC 4385 [2]. 272 Additional Channel Type values and the associated maintenance 273 functionality will be defined in other documents. Each document, 274 specifying a protocol solution relying on the ACH, MUST also specify 275 the applicable Channel Type field value. 277 Note that these values are allocated from the PW Associated Channel 278 Type registry [4], but this document modifies the existing policy to 279 accommodate a level of experimentation. See Section 10 for further 280 details. 282 3. ACH TLVs 284 In some applications of the generalized associated control channel it 285 is necessary to include one or more ACH TLVs to provide additional 286 context information to the G-ACh packet. One use of these ACH TLVs 287 might be to identify the source and/or intended destination of the 288 associated channel message. However, the use of this construct is 289 not limited to providing addressing information nor is the 290 applicability restricted to transport network applications. 292 If the G-ACh message MAY be preceded by one or more ACH TLVs, then 293 this MUST be explicitly specified in the definition of an ACH Channel 294 Type. If the ACH Channel Type definition does state that one or more 295 ACH TLVs MAY precede the G-ACh message, an ACH TLV Header MUST follow 296 the ACH. If no ACH TLVs are required in a specific associated 297 channel packet, but the Channel Type nevertheless defines that ACH 298 TLVs MAY be used, an ACH TLV Header MUST be present but with a length 299 field set to zero to indicate that no ACH TLV follow this header. 301 If an ACH Channel Type specification does not explicitly specify that 302 ACH TLVs MAY be used, then the ACH TLV Header MUST NOT be used. 304 3.1. ACH TLV Payload Structure 306 This section defines and describes the structure of an ACH payload 307 when an ACH TLV Header is present. 309 The following figure (Figure 2) shows the structure of a G-ACh packet 310 payload. 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | ACH | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | ACH TLV Header | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | ~ 318 ~ zero or more ACH TLVs ~ 319 ~ | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | ~ 322 ~ G-ACh Message ~ 323 ~ | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Figure 2: G-ACh Packet Payload 328 3.2. ACH TLV Header 330 The ACH TLV Header defines the length of the set of ACH TLVs that 331 follow. 333 0 1 2 3 334 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Length | Reserved | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Figure 3: ACH TLV Header 341 The Length field specifies the length in octets of the complete set 342 of TLVs including sub-TLVs that follow the ACH TLV header. A length 343 of zero indicates that no ACH TLV follow this header. Note that no 344 padding is required for the set of ACH TLVs. 346 The Reserved field is for future use and MUST be set to zero on 347 transmission and ignored on reception. 349 3.3. ACH TLV Object 351 ACH TLVs MAY follow an ACH TLV header. The structure of ACH TLVs is 352 defined and described in this section. 354 An ACH TLV consists of a 16-bit Type field, followed by a 16-bit 355 Length field which specifies the number of octets of the Value field 356 which follows the Length field. This 32-bit word is followed by zero 357 or more octets of Value information. The format and semantics of the 358 Value information are defined by the TLV Type as recorded in the TLV 359 Type registry. See Section 10 for further details. Note that the 360 Value field of ACH TLVs MAY contain sub-TLVs. Note that no padding 361 is required for individual TLVs or sub-TLVs. 363 0 1 2 3 364 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | TLV Type | Length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | ~ 369 ~ Value ~ 370 ~ | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Figure 4: ACH TLV Format 375 4. Generalized Exception Mechanism 377 Generalizing the associated control channel mechanism to LSPs and 378 Sections also requires a method to identify that a packet contains an 379 ACH followed by a non-service payload. This document specifies that 380 a label is used for that purpose and calls this special label the 381 G-ACh Label (GAL). One of the reserved label values defined in RFC 382 3032 [5] is assigned for this purpose. The value of the label is to 383 be allocated by IANA. 385 The GAL provides an alert based exception mechanism to: 387 o differentiate specific packets (i.e., G-ACh packets) from others, 388 such as user-plane ones, 390 o indicate that the ACH appears immediately after the bottom of the 391 label stack. 393 The GAL MUST only be used where both these purposes apply. 395 4.1. Relationship with Existing MPLS OAM Alert Mechanisms 397 RFC 4379 [13] and BFD-MPLS [12] define alert mechanisms that enable 398 an MPLS LSR to identify and process MPLS OAM packets when these are 399 encapsulated in an IP header. These alert mechanisms are based, for 400 example, on Time To Live (TTL) expiration and/or on the use of an IP 401 destination address in the range of 127.0.0.0/8 or 0:0:0:0:0:FFFF: 402 127.0.0.0/104, respectively for IPv4 and IPv6. 404 These mechanisms are the default mechanisms for identifying MPLS OAM 405 packets when encapsulated in an IP header although the mechanism 406 defined in this document MAY also be used. 408 4.2. GAL Applicability and Usage 410 In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, 411 Concatenated Segments of LSPs, and with Sections, and MUST NOT be 412 used with PWs. It MUST always be at the bottom of the label stack 413 (i.e., S bit set to 1). However, in other MPLS environments, this 414 document places no restrictions on where the GAL may appear within 415 the label stack or its use with PWs. Where the GAL is at the bottom 416 of the label stack (i.e., S bit set to 1) then it MUST always be 417 followed by an ACH. 419 The GAL MUST NOT appear in the label stack when transporting normal 420 user-plane packets. Furthermore, when present, the GAL MUST NOT 421 appear more than once in the label stack. 423 A receiving LSR, LER or PE MUST NOT forward a G-ACh packet to another 424 node based on the GAL label. 426 4.2.1. GAL Processing 428 The Traffic Class (TC) field (formerly known as the EXP field) of the 429 Label Stack Entry (LSE) containing the GAL follows the definition and 430 processing rules specified and referenced in [6]. 432 The Time-To-Live (TTL) field of the LSE that contains the GAL follows 433 the definition and processing rules specified in [7]. 435 4.2.1.1. MPLS Label Switched Paths and Segments 437 The following figure (Figure 5) depicts two LERs (A and D) and two 438 LSRs (B and C) for a given LSP which is established from A to D and 439 switched in B and C. 441 +---+ +---+ +---+ +---+ 442 | A |-------------| B |-------------| C |-------------| D | 443 +---+ +---+ +---+ +---+ 445 Figure 5: Maintenance over a LSP 447 In this example, a G-ACh exists on the LSP that extends between LERs 448 A and D, via LSRs B and C. Only A and D may initiate new G-ACh 449 packets. A, B, C and D may process and respond to G-ACh packets. 451 The following figure (Figure 6) depicts the format of an MPLS-TP 452 G-ACh packet when used for an LSP. 454 0 1 2 3 455 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | LSP Label | TC |S| TTL | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | GAL | TC |S| TTL | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | ACH | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | ACH TLV Header (if present) | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | ~ 466 ~ Zero or more ACH TLVs ~ 467 ~ (if present) | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | ~ 470 ~ G-ACh Message ~ 471 ~ | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 Figure 6: G-ACh packet format for a LSP 476 Note that it is possible that the LSP may be tunneled in another LSP 477 (e.g., if a MPLS Tunnel exists between B and C), and as such other 478 LSEs may be present in the label stack. 480 To send a G-ACh message on the LSP associated control channel, the 481 LER (A) generates a G-ACh message, to which it MAY prepend an ACH TLV 482 Header and appropriate ACH TLVs. It then adds an ACH, onto which it 483 pushes a GAL LSE. Finally, the LSP Label LSE is pushed onto the 484 resulting packet. 486 o The TTL field of the GAL LSE MUST be set to at least 1. The exact 487 value of the TTL is application specific. See Section 4.2.1 for 488 definition and processing rules. 490 o The S bit of the GAL MUST be set according to its position in the 491 label stack (see Section 4.2). 493 o The setting of the TC field of the GAL is application specific. 494 See Section 4.2.1 for definition and processing rules. 496 LSRs MUST NOT modify the G-ACh message, the ACH or the GAL towards 497 the targeted destination. 499 Note: This is because once a G-ACh packet has been sent on an LSP, 500 no node has visibility of it unless the LSP label TTL expires or 501 the GAL is exposed when the LSP label is popped. If this is at 502 the targeted destination, for example indicated by an address in 503 an ACH TLV, then processing can proceed as specified below. If 504 this is not the targeted destination, but the node has agreed to 505 process packets on that ACH channel, then the processing applied 506 to the packet is out of scope of this document. 508 Upon reception of the labeled packet, the targeted destination, after 509 having checked both the LSP Label and GAL LSEs fields, SHOULD pass 510 the whole packet to the appropriate processing entity. 512 4.2.1.2. MPLS Section 514 The following figure (Figure 7) depicts an example of an MPLS 515 Section. 517 +---+ +---+ 518 | A |-------------| Z | 519 +---+ +---+ 521 Figure 7: Maintenance over an MPLS Section 523 With regard to the MPLS Section, a G-ACh exists between A and Z. Only 524 A and Z can insert, extract or process packets on this G-ACh. 526 The following figure (Figure 8) depicts the format of a G-ACh packet 527 when used for an MPLS Section. The GAL MAY provide the exception 528 mechanism for a control channel in its own right without being 529 associated with a specific LSP, thus providing maintenance related 530 communications across a specific link interconnecting two LSRs. In 531 this case, the GAL is the only label in the stack. 533 0 1 2 3 534 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | GAL | TC |S| TTL | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | ACH | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | ACH TLV Header (if present) | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | ~ 543 ~ Zero or more ACH TLVs ~ 544 ~ (if present) | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | ~ 547 ~ G-ACh message ~ 548 ~ | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 Figure 8: G-ACh packet format for an MPLS Section 553 To send a G-ACh message on a control channel associated to the 554 Section, the head-end LSR (A) of the Section generates a G-ACh 555 message, to which it MAY prepend an ACH TLV Header and appropriate 556 ACH TLVs. Next the LSR adds an ACH. Finally it pushes a GAL LSE. 558 o The TTL field of the GAL MUST be set to at least 1. The exact 559 value of the TTL is application specific. See Section 4.2.1 for 560 definition and processing rules. 562 o The S bit of the GAL MUST be set according to its position in the 563 label stack. (see Section 4.2). 565 o The setting of the TC field of the GAL is application specific. 566 See Section 4.2.1 for definition and processing rules. 568 Intermediate nodes of the MPLSsection MUST NOT modify the G-ACh 569 message, the ACH and the GAL towards the tail-end LSR (Z). Upon 570 reception of the G-ACh packet, the tail-end LSR (Z), after having 571 checked the GAL LSE fields, SHOULD pass the whole packet to the 572 appropriate processing entity. 574 4.3. Relationship with RFC 3429 576 RFC 3429 [18] describes the assignment of one of the reserved label 577 values, defined in RFC 3032 [5], to the 'OAM Alert Label' that is 578 used by user-plane MPLS OAM functions for the identification of MPLS 579 OAM packets. The value of 14 is used for that purpose. 581 Both this document and RFC 3429 [18] therefore describe the 582 assignment of reserved label values for similar purposes. The 583 rationale for the assignment of a new reserved label can be 584 summarized as follows: 586 o Unlike the mechanisms described and referenced in RFC 3429 [18], 587 G-ACh messages will not reside immediately after the GAL but 588 instead behind the ACH, which itself resides after the bottom of 589 the label stack. 591 o The set of maintenance functions potentially operated in the 592 context of the G-ACh is wider than the set of OAM functions 593 referenced in RFC 3429 [18]. 595 o It has been reported that there are existing implementations and 596 running deployments using the 'OAM Alert Label' as described in 597 RFC 3429 [18]. It is therefore not possible to modify the 'OAM 598 Alert Label' allocation, purpose or usage. Nevertheless, it is 599 RECOMMENDED that no further OAM extensions based on 'OAM Alert 600 Label' (Label 14) usage be specified or developed. 602 5. Compatibility 604 Procedures for handling a packet received with an invalid incoming 605 label are specified in RFC 3031[8]. 607 An LER, LSR or PE MUST discard received associated channel packets on 608 which all of the MPLS or PW labels have been popped if any one of the 609 following conditions is true: 611 o It is not capable of processing packets on the Channel Type 612 indicated by the ACH of the received packet. 614 o It has not, through means outside the scope of this document, 615 indicated to the sending LSR, LER or PE that it will process 616 associated channel packets on the Channel Type indicated by the 617 ACH of the received packet. 619 o The packet is received on an Experimental Channel Type that is 620 locally disabled. 622 o If the ACH was indicated by the presence of a GAL, and the first 623 nibble of the ACH of the received packet is not 0001b. 625 o The ACH version is not recognized. 627 In addition, the LER, LSR or PE MAY increment an error counter and 628 MAY also issue a system and/or SNMP notification. 630 6. Congestion Considerations 632 The congestion considerations detailed in RFC 5085 [1] apply. 634 7. Major Contributing Authors 636 The editors would like to thank George Swallow, David Ward, and Rahul 637 Aggarwal, who made a major contribution to the developement of this 638 document. 640 8. Acknowledgments 642 The editors gratefully acknowledge the contributions of Sami Boutros, 643 Italo Busi, Marc Lasserre, Lieven Levrau and Siva Sivabalan. 645 The authors would also like to thank Malcolm Betts, ITU-T Study Group 646 15, and all members of the teams (the Joint Working Team, the MPLS 647 Interoperability Design Team in IETF and the MPLS-TP Ad-Hoc Team in 648 ITU-T) involved in the definition and specification of the MPLS 649 Transport Profile. 651 9. Security Considerations 653 The security considerations for the associated control channel are 654 described in RFC 4385 [2]. Further security considerations MUST be 655 described in the relevant associated channel type specification. 657 RFC 5085 [1] provides data plane related security considerations. 658 These also apply to a G-ACh, whether the alert mechanism uses a GAL 659 or only an ACH. 661 10. IANA Considerations 663 This document requests that IANA allocates a label value, to the GAL, 664 from the pool of reserved labels in the "Multiprotocol Label 665 Switching Architecture (MPLS) Label Values" registry, and suggests 666 this value to be 13. 668 Note to RFC Editor: The above text "and suggests this value to be 669 13" needs to be replaced with "with a value of 13." when the RFC 670 is published and IANA has allocated the value. 672 Channel Types for the Associated Channel Header are allocated from 673 the IANA "PW Associated Channel Type" registry [4]. The PW 674 Associated Channel Type registry is currently allocated based on the 675 IETF consensus process (termed "IETF Review" in [9]). This 676 allocation process was chosen based on the consensus reached in the 677 PWE3 working group that pseudowire associated channel mechanisms 678 should be reviewed by the IETF and only those that are consistent 679 with the PWE3 architecture and requirements should be allocated a 680 code point. 682 However, a requirement has emerged (see [15]) to allow for 683 optimizations or extensions to OAM and other control protocols 684 running in an associated channel to be experimented without resorting 685 to the IETF standards process, by supporting experimental code 686 points. This would prevent code points used for such functions from 687 being used from the range allocated through the IETF standards and 688 thus protects an installed base of equipment from potential 689 inadvertent overloading of code points. In order to support this 690 requirement, this document requests that the code point allocation 691 scheme for the PW Associated Channel Type be changed as follows: 693 0 - 32751 : IETF Review 695 32760 - 32767 : Experimental 697 Code points in the experimental range MUST be used according to the 698 guidelines of RFC 3692 [10]. Functions using experimental G-ACh code 699 points MUST be disabled by default. The Channel Type value used for 700 a given experimental OAM function MUST be configurable, and care MUST 701 be taken to ensure that different OAM functions that are not inter- 702 operable are configured to use different Channel Type values. 704 The PW Associated Channel Type registry needs to be updated to 705 include a column indicating whether the ACH is followed by a ACH TLV 706 header (Yes/No). There are two ACH Channel Type code-points 707 currently assigned and in both cases no ACH TLV header is used. Thus 708 the new format of the PW Channel Type registry is: 710 Registry: 711 Value Description TLV Follows Reference 712 ----- ---------------------------- ----------- --------- 713 0x21 ACH carries an IPv4 packet No [RFC4385] 714 0x57 ACH carries an IPv6 packet No [RFC4385] 716 Figure 9: PW Channel Type registry 718 IANA is requested create a new registry called the Associated Channel 719 Header TLV Registry. The allocation policy for this registry is IETF 720 review. This registry MUST record the following information. There 721 are no initial entries. 723 Name Type Length Description Reference 724 (octets) 726 Figure 10: ACH TLV registry 728 11. References 730 11.1. Normative References 732 [1] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 733 Connectivity Verification (VCCV): A Control Channel for 734 Pseudowires", RFC 5085, December 2007. 736 [2] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 737 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use 738 over an MPLS PSN", RFC 4385, February 2006. 740 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 741 Levels", BCP 14, RFC 2119, March 1997. 743 [4] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 744 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 746 [5] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, 747 D., Li, T., and A. Conta, "MPLS Label Stack Encoding", 748 RFC 3032, January 2001. 750 [6] Andersson, L. and R. Asati, "Multiprotocol Label Switching 751 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 752 Class" Field", RFC 5462, February 2009. 754 [7] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in 755 Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, 756 January 2003. 758 [8] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label 759 Switching Architecture", RFC 3031, January 2001. 761 [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 762 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 764 [10] Narten, T., "Assigning Experimental and Testing Numbers 765 Considered Useful", BCP 82, RFC 3692, January 2004. 767 11.2. Informative References 769 [11] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in 770 Transport Networks", draft-ietf-mpls-tp-framework-00 (work in 771 progress), November 2008. 773 [12] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD 774 For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress), 775 June 2008. 777 [13] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label 778 Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 780 [14] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 781 Detection (BFD) for the Pseudowire Virtual Circuit 782 Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-04 783 (work in progress), May 2009. 785 [15] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in 786 MPLS Transport Networks", 787 draft-ietf-mpls-tp-oam-requirements-01 (work in progress), 788 March 2009. 790 [16] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and 791 S. Ueno, "MPLS-TP Requirements", 792 draft-ietf-mpls-tp-requirements-08 (work in progress), 793 May 2009. 795 [17] International Telecommunication Union, "Generic Functional 796 Architecture of Transport Networks", ITU-T G.805, March 2000. 798 [18] Ohta, H., "Assignment of the 'OAM Alert Label' for 799 Multiprotocol Label Switching Architecture (MPLS) Operation and 800 Maintenance (OAM) Functions", RFC 3429, November 2002. 802 Authors' Addresses 804 Matthew Bocci (editor) 805 Alcatel-Lucent 806 Voyager Place, Shoppenhangers Road 807 Maidenhead, Berks SL6 2PJ 808 UK 810 Email: matthew.bocci@alcatel-lucent.com 812 Martin Vigoureux (editor) 813 Alcatel-Lucent 814 Route de Villejust 815 Nozay, 91620 816 France 818 Email: martin.vigoureux@alcatel-lucent.com 820 Stewart Bryant 821 Cisco 823 Email: stbryant@cisco.com 825 George Swallow 826 Cisco 828 Email: swallow@cisco.com 830 David Ward 831 Cisco 833 Email: dward@cisco.com 835 Rahul Aggarwal 836 Juniper Networks 838 Email: rahul@juniper.net