idnits 2.17.1 draft-bocci-pwe3-mpls-tp-ge-ach-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 345. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 351. 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 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 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 (June 26, 2008) is 5776 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 normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) == Outdated reference: A later version (-01) exists of draft-vigoureux-mpls-tp-oam-requirements-00 -- Obsolete informational reference (is this intentional?): RFC 4379 (ref. '7') (Obsoleted by RFC 8029) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M.Bocci, (Ed.) 2 Internet Draft Alcatel-Lucent 4 D.Ward, (Ed.) 5 Cisco 7 Intended status: Proposed Standard June 26, 2008 8 Expires: December 2008 10 MPLS Generic Associated Channel 12 draft-bocci-pwe3-mpls-tp-ge-ach-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that 17 any applicable patent or other IPR claims of which he or she is 18 aware have been or will be disclosed, and any of which he or she 19 becomes aware will be disclosed, in accordance with Section 6 of 20 BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on December 26, 2008. 40 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This draft describes a generic associated channel header (GE-ACH) 46 that provides a control channel associated with an MPLS LSP, 47 pseudowire or MPLS section. The VCCV ACH defined for PWs in RFC 5085 48 is generalized to allow a larger set of control channel and OAM 49 functions to be used to meet the requirements of packet transport and 50 other applications of MPLS. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119 [1]. 58 Table of Contents 60 1. Introduction................................................2 61 1.1. Contributing Authors....................................3 62 1.2. Objectives.............................................3 63 1.3. Scope..................................................3 64 1.4. Terminology............................................4 65 2. Generic Associated Channel...................................4 66 2.1. Generic Associated Channel Header.......................4 67 3. Congestion Considerations....................................5 68 4. Security Considerations......................................5 69 5. IANA Considerations.........................................5 70 6. Acknowledgments.............................................6 71 7. References..................................................6 72 7.1. Normative References....................................6 73 7.2. Informative References..................................7 74 Author's Addresses.............................................7 75 Intellectual Property Statement.................................8 77 1. Introduction 79 There is a need for Operations and Maintenance (OAM) mechanisms that 80 can be used for edge-to-edge (i.e. between originating and 81 terminating LSRs or T-PEs) and segment fault detection (e.g. between 82 any two LSRs or S-PEs along the path of an LSP or PW), diagnostics, 83 maintenance and other functions for a Pseudowire and an LSP. Some of 84 these functions can be supported using tools such as VCCV [3], BFD 85 [8], or LSP-Ping [7]. However, a requirement has been indicated to 86 extend these toolsets, in particular where MPLS networks are used for 87 packet transport services and network operations [6]. These include 88 performance monitoring, automatic protection switching, and support 89 for management and signaling communication channels. These tools must 90 be applicable to, and function in essentially the same manner (from 91 an operational point of view) on both MPLS PWs and MPLS LSPs. They 92 must also operate in-band on the PW or LSP such that they do not 93 depend on PSN routing, user data traffic or ultimately on control 94 plane functions. 96 Virtual Circuit Connectivity Verification (VCCV) can use an 97 associated channel to provide a control channel between a PW's 98 ingress and egress points over which OAM and other control messages 99 can be exchanged. In this draft, we propose a generic associated 100 channel header (GE-ACH) to enable the same control channel mechanism 101 be used for MPLS Sections, LSPs and PWs. The associated channel 102 header (ACH) specified in RFC 4385 [2] is used with additional code 103 points to support additional MPLS OAM functions. 105 1.1. Contributing Authors 107 The editors gratefully acknowledge the following additional 108 contributors: Stewart Bryant, Italo Busi, Marc Lasserre, Lieven 109 Levrau, and Martin Vigoureux. 111 1.2. Objectives 113 This draft proposes a mechanism to provide for the OAM needs of 114 transport applications. It creates a generic OAM identification 115 mechanism that may be applied to all MPLS LSPs, while maintaining 116 compatibility with the PW associated channel header (ACH) [2]. It 117 also normalizes the use of the ACH for PWs in a transport context. 119 1.3. Scope 121 This draft defines the encapsulation header for LSP, MPLS Section and 122 PW associated channel messages. 124 It does not define how associated channel capabilities are signaled 125 or negotiated between LSRs or PEs, the operation of various OAM 126 functions, or the messages transmitted on the associated channel. 128 This draft does not deprecate existing MPLS and PW OAM mechanisms. 130 1.4. Terminology 132 ACH: Associated Channel Header 134 MPLS Section: A Section is a network segment between two LSRs that 135 are immediately adjacent. 137 2. Generic Associated Channel 139 VCCV [3] defines three control channel types that may be used to 140 multiplex OAM messages onto a PW. CC type 1, uses an associated 141 channel header and is referred to as "In-band VCCV", CC type 2 which 142 uses the router alert label to indicate VCCV packets and is referred 143 to as "Out of Band VCCV", and CC type 3 that uses the TTL to force 144 the packet to be processed by the destination routers control plane 145 (known as "MPLS PW Label with TTL == 1"). 147 This draft proposes that in transport applications only the type 1 148 (associated channel header) mechanism is used for LSP OAM and for PW 149 OAM. In transport applications a static or traffic engineered LSP is 150 normally used, thus the data and the OAM will follow the same path. 151 This does not preclude the use of the GE-ACH mechanism described in 152 this draft for other applications of MPLS. 154 Note that VCCV also includes mechanisms for negotiating the control 155 channel and connectivity verification (i.e. OAM tool) types between 156 PEs. These mechanisms need to be extended when a generic associated 157 channel is used for MPLS LSP OAM. This will most likely require 158 extensions to label distribution protocols and is outside the scope 159 of this document. 161 This section defines a generic associated channel header (GE-ACH) 162 that identifies packets on the associated channel. 164 2.1. Generic Associated Channel Header 166 The format of the GE-ACH for LSP, Section and PW associated channel 167 traffic is shown in Figure 1: 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 |0 0 0 1|Version| Reserved | Channel Type | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 1 Generic Associated Channel Header 177 The first nibble is set to 0001b to indicate a channel associated 178 with a PW or LSP. The Version and Reserved fields are set to 0, as 179 specified in RFC 4385 [2]. 181 Values for the channel type used for VCCV are specified in RFC 4446 182 [4]. 184 This draft specifies the following additional channel types: 186 0xXX - for OAM functions 188 0xYY - for APS functions 190 0xKK - for Management Communications Channel (MCC) functions 192 0xZZ - for Signaling Communications Channel (SCC) functions 194 The functionality of these channel types will be defined elsewhere. 196 3. Congestion Considerations 198 The congestion considerations detailed in RFC 5085 [1] apply. Further 199 generic associated channel-specific congestion considerations will be 200 detailed in a future revision of this draft. 202 4. Security Considerations 204 The security considerations detailed in RFC 5085 [1] apply. Further 205 generic associated channel-specific security considerations will be 206 detailed in a future revision of this draft. 208 5. IANA Considerations 210 This draft requests that code points for the following GE-ACH channel 211 types be allocated from the IANA PW Associated Channel Type registry 212 [4]: 214 0xXX - for OAM functions 216 0xYY - for APS functions 218 0xKK - for Management Communications Channel (MCC) functions 220 0xZZ - for Signaling Communications Channel (SCC) functions 221 The PW Associated Channel Type registry is currently allocated based 222 on the IETF consensus process, described in [5]. This allocation 223 process was chosen based on the consensus reached in the PWE3 working 224 group that pseudowire associated channel mechanisms should be 225 reviewed by the IETF and only those that are consistent with the PWE3 226 architecture and requirements should be allocated a code point. 228 However, a requirement has emerged to allow for vendor-specific 229 optimizations or extensions to OAM and other control protocols 230 running in an associated channel, by supporting vendor specific code 231 points [6]. This would prevent code points used for such functions 232 from being allocated through the IETF standards process in future. 233 Vendor specific code point space thus protects an installed base of 234 equipment from potential inadvertent overloading of code points. 236 Each draft specifying ACH protocols must provide a solution for 237 supporting vendor-specific types, in accordance with [6], in addition 238 to those allocated by IETF consensus. The details of these solutions 239 are outside the scope of this draft. 241 6. Acknowledgments 243 The authors gratefully acknowledge the input of Lou Berger, George 244 Swallow and Rahul Aggarwal. 246 7. References 248 7.1. Normative References 250 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 251 Levels", BCP 14, RFC 2119, March 1997. 253 [2] S. Bryant et al., "Pseudowire Emulation Edge-to-Edge (PWE3) 254 Control Word for Use over an MPLS PSN", RFC 4385, February 2006 256 [3] Nadeau, T. & Pignataro, S., "Pseudowire Virtual Circuit 257 Connectivity Verification (VCCV): A Control Channel for 258 Pseudowires", RFC 5085, December 2007 260 [4] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 261 Emulation (PWE3)", RFC 4446, April 2006 263 [5] Narten, T., Alvestrand, H., " Guidelines for Writing an IANA 264 Considerations Section in RFCs", RFC 2434, October 1998 266 7.2. Informative References 268 [6] M. Vigoureux et al., "Requirements for OAM in MPLS Transport 269 Networks", draft-vigoureux-mpls-tp-oam-requirements-00.txt, 270 June 2008 272 [7] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label 273 Switched (MPLS) Data Plane Failures", RFC 4379, February 2006 275 [8] R. Aggarwal et al, "BFD for MPLS LSPs", draft-ietf-bfd-mpls- 276 07.txt, June 2008 278 Author's Addresses 280 Matthew Bocci, (Ed.) 281 Alcatel-Lucent 282 Voyager Place, 283 Maidenhead, 284 Berks, UK 285 Phone: +44 1633 413600 286 Email: matthew.bocci@alcatel-lucent.co.uk 288 David Ward, (Ed.) 289 Cisco 290 170 W. Tasman Dr. 291 San Jose, CA 95134 USA 292 Phone: +1-408-526-4000 293 Email: dward@cisco.com 295 Stewart Bryant 296 Cisco 297 250, Longwater, 298 Green Park, 299 Reading, RG2 6GB, 300 United Kingdom. 301 Email: stbryant@cisco.com 302 Italo Busi, 303 Alcatel-Lucent 304 VIA TRENTO 30, 305 20059 VIMERCATE ITALY 306 Email: italo.busi@alcatel-lucent.it 308 Marc Lasserre 309 Alcatel-Lucent 310 16 Avenue Descartes, 311 92352 LE PLESSIS ROBINSON CEDE, 312 France 313 Email: mlaserre@alcatel-lucent.com 315 Lieven Levrau 316 Alcatel-Lucent 317 7-9, Avenue Morane, 318 Saulnier BP 57 78141, 319 VELIZY, 320 France 321 Email: llevrau@alcatel-lucent.com 323 Martin Vigoureux 324 Alcatel-Lucent 325 Centre De Villarceaux, 326 France 327 Email: martin.vigoureux@alcatel-lucent.fr 329 Intellectual Property Statement 331 The IETF takes no position regarding the validity or scope of any 332 Intellectual Property Rights or other rights that might be claimed to 333 pertain to the implementation or use of the technology described in 334 this document or the extent to which any license under such rights 335 might or might not be available; nor does it represent that it has 336 made any independent effort to identify any such rights. Information 337 on the procedures with respect to rights in RFC documents can be 338 found in BCP 78 and BCP 79. 340 Copies of IPR disclosures made to the IETF Secretariat and any 341 assurances of licenses to be made available, or the result of an 342 attempt made to obtain a general license or permission for the use of 343 such proprietary rights by implementers or users of this 344 specification can be obtained from the IETF on-line IPR repository at 345 http://www.ietf.org/ipr. 347 The IETF invites any interested party to bring to its attention any 348 copyrights, patents or patent applications, or other proprietary 349 rights that may cover technology that may be required to implement 350 this standard. Please address the information to the IETF at 351 ietf-ipr@ietf.org. 353 Full Copyright Statement 355 Copyright (C) The IETF Trust (2008). 357 This document is subject to the rights, licenses and restrictions 358 contained in BCP 78, and except as set forth therein, the authors 359 retain all their rights. 361 This document and the information contained herein are provided on an 362 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 363 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 364 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 365 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 366 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 367 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 369 Acknowledgment 371 Funding for the RFC Editor function is currently provided by the 372 Internet Society.