idnits 2.17.1 draft-ietf-pwe3-iana-allocation-15.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 314. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: IANA is requested to create several registries as described in the following paragraphs. Each of these registries contains numeric values used to identify data types. In each of these registries the value of 0 is reserved, and MUST not be used. -- 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 (November 2005) is 6734 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) == Unused Reference: 'RFC2277' is defined on line 322, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'BCP78' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'RFC1144' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC2507' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'RFC2508' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'RFC3095' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'RFC3545' is defined on line 396, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3979 (ref. 'BCP79') (Obsoleted by RFC 8179) ** Obsolete normative reference: RFC 3978 (ref. 'BCP78') (Obsoleted by RFC 5378) == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-16 == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-vccv-07 == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-fragmentation-09 == Outdated reference: A later version (-14) exists of draft-ietf-pwe3-sonet-11 == Outdated reference: A later version (-05) exists of draft-ietf-pwe3-satop-03 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-frame-relay-02 == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-atm-encap-05 -- No information found for draft-ietf-pwe3-hdlc-ppp-encap - is the name correct? == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-ethernet-encap-06 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-cesopsn-03 == Outdated reference: A later version (-06) exists of draft-ietf-pwe3-tdmoip-04 == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-signaling-06 Summary: 6 errors (**), 0 flaws (~~), 23 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini 3 Internet Draft 4 Expiration Date: May 2006 Cisco Systems Inc. 6 November 2005 8 IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3) 10 draft-ietf-pwe3-iana-allocation-15.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document allocates the fixed Pseudo-wire identifier , and other 37 fixed protocol values for protocols that have been defined in the 38 pseudo wire edge to edge working group. ( PWE3 ) Detailed IANA 39 allocation instructions are also included in this document. 41 Table of Contents 43 1 Specification of Requirements .......................... 2 44 2 Introduction ........................................... 2 45 3 IANA Considerations .................................... 3 46 3.1 Expert Review Directives ............................... 3 47 3.2 MPLS Pseudowire Type ................................... 3 48 3.3 Interface Parameters Sub-TLV type ...................... 4 49 3.4 Attachment Identifiers ................................. 5 50 3.4.1 Attachment Individual Identifier Type .................. 5 51 3.4.2 Attachment Group Identifier (AGI) Type ................. 6 52 3.5 Pseudo Wire Status ..................................... 6 53 4 Security Considerations ................................ 7 54 5 Full Copyright Statement ............................... 7 55 6 Intellectual Property Statement ........................ 7 56 7 Normative References ................................... 8 57 8 Informative References ................................. 8 58 9 Author Information ..................................... 10 60 1. Specification of Requirements 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119] 66 2. Introduction 68 Most of the new IANA registries, and respective iana allocation 69 processes for protocols defined in the PWE3 IETF working group can be 70 found in this document. The IANA registries defined here, are in 71 general subdivided into three main ranges: a range to be allocated by 72 IETF consensus according to [RFC2434], a range to be allocated by the 73 expert review process according to [RFC2434], and a range to be 74 allocated in a first come first served basis reserved for vendor 75 proprietary allocations. It should be noted that vendor proprietary 76 types MUST NOT be registered for IETF standards or extensions of 77 those, whether still in development or already completed. 79 3. IANA Considerations 81 IANA is requested to create several registries as described in the 82 following paragraphs. Each of these registries contains numeric 83 values used to identify data types. In each of these registries the 84 value of 0 is reserved, and MUST not be used. 86 3.1. Expert Review Directives 88 Throughout this document allocation procedures for several registries 89 call for an expert review process according to [RFC2434]. The expert 90 should consider the following points: 92 * Avoid Duplication of code point allocations. 93 * A brief clear description of the code point allocation requested. 94 * Whether the type allocation requested is appropriate for the 95 particular requested value range in the registry. 97 The Expert reviewing the request MUST provide an answer, approving, 98 or disapproving the request within 10 business days from when the he 99 or she received the expert review request. 101 3.2. MPLS Pseudowire Type 103 IANA needs to set up a registry of "MPLS Pseudowire Type". These are 104 15-bit values. PW Type values 1 through 30 are specified in this 105 document, PW Type values 31 through 1024 are to be assigned by IANA, 106 using the "Expert Review" policy defined in [RFC2434]. PW Type values 107 1025 through 4096, and 32767 are to be allocated using the IETF 108 consensus policy defined in [RFC2434]. PW Type values 4097 through 109 32766 are reserved for vendor proprietary extensions and are to be 110 assigned by IANA, using the "First Come First Served" policy defined 111 in [RFC2434]. A Pseudowire Type description is required for any 112 assignment from this registry. Additionally, for the vendor 113 proprietary extensions range a citation of a person or company name 114 is also required. A document reference should also be provided. 116 Initial Pseudowire type value allocations are specified below: 118 PW type Description Reference 119 0x0001 Frame Relay DLCI ( Martini Mode ) [FRAME] 120 0x0002 ATM AAL5 SDU VCC transport [ATM] 121 0x0003 ATM transparent cell transport [ATM] 122 0x0004 Ethernet Tagged Mode [ETH] 123 0x0005 Ethernet [ETH] 124 0x0006 HDLC [PPPHDLC] 125 0x0007 PPP [PPPHDLC] 126 0x0008 SONET/SDH Circuit Emulation Service Over MPLS [CEP] 127 0x0009 ATM n-to-one VCC cell transport [ATM] 128 0x000A ATM n-to-one VPC cell transport [ATM] 129 0x000B IP Layer2 Transport [RFC3032] 130 0x000C ATM one-to-one VCC Cell Mode [ATM] 131 0x000D ATM one-to-one VPC Cell Mode [ATM] 132 0x000E ATM AAL5 PDU VCC transport [ATM] 133 0x000F Frame-Relay Port mode [FRAME] 134 0x0010 SONET/SDH Circuit Emulation over Packet [CEP] 135 0x0011 Structure-agnostic E1 over Packet [SAToP] 136 0x0012 Structure-agnostic T1 (DS1) over Packet [SAToP] 137 0x0013 Structure-agnostic E3 over Packet [SAToP] 138 0x0014 Structure-agnostic T3 (DS3) over Packet [SAToP] 139 0x0015 CESoPSN basic mode [CESoPSN] 140 0x0016 TDMoIP AAL1 Mode [TDMoIP] 141 0x0017 CESoPSN TDM with CAS [CESoPSN] 142 0x0018 TDMoIP AAL2 Mode [TDMoIP] 143 0x0019 Frame Relay DLCI [FRAME] 145 3.3. Interface Parameters Sub-TLV type 147 IANA needs to set up a registry of "Pseudowire Interface Parameter 148 Sub-TLV types". These are 8 bit values. Sub-TLV types 1 through 12 149 are specified in this document. Sub-TLV types 13 through 64 are to be 150 assigned by IANA, using the "Expert Review" policy defined in 151 [RFC2434]. Sub-TLV types 65 through 127, and 255 are to be allocated 152 using the IETF consensus policy defined in [RFC2434]. Sub-TLV types 153 values 128 through 254 are reserved for vendor proprietary extensions 154 and are to be assigned by IANA, using the "First Come First Served" 155 policy defined in [RFC2434]. 157 Any assignments requested from this registry require a description up 158 to 54 characters. 160 For each allocation a length field MUST also be specified in one of 161 the following formats: 162 - Text as follows:"up to X", where X is a decimal integer 163 - Up to 3 different decimal integers. 165 The text "up to X" is meant to mean up to and including X. 167 Additionally, for the vendor proprietary extensions range a citation 168 of a person or company name is also required. A document reference 169 should also be provided. 171 Initial Pseudowire Interface Parameter Sub-TLV type allocations are 172 specified below: 174 Parameter ID Length Description Reference 175 0x01 4 Interface MTU in octets [CRTL] 176 0x02 4 Maximum Number of concatenated ATM cells [ATM] 177 0x03 up to 82 Optional Interface Description string[CRTL] 178 0x04 4 CEP/TDM Payload Bytes [CEP/TDM] 179 0x05 4 CEP options [CEP] 180 0x06 4 Requested VLAN ID [ETH] 181 0x07 6 CEP/TDM bit-rate [CEP/TDM] 182 0x08 4 Frame-Relay DLCI Length [FRAME] 183 0x09 4 Fragmentation indicator [FRAG] 184 0x0A 4 FCS retention indicator [FCS] 185 0x0B 4/8/12 TDM options [TDMoIP] 186 0x0C 4 VCCV parameter [VCCV] 188 Note that the Length field is defined as the length of the Sub-TLV 189 including the Sub-TLV type and length field itself. 191 3.4. Attachment Identifiers 193 3.4.1. Attachment Individual Identifier Type 195 IANA needs to set up a registry of "Attachment Individual Identifier 196 (AII) Type". These are 8-bit values. AII Type value 1 is defined in 197 this document. AII Type values 2 through 64 are to be assigned by 198 IANA using the "Expert Review" policy defined in [RFC2434]. AII Type 199 values 65 through 127, and 255 are to be allocated using the IETF 200 consensus policy defined in [RFC2434]. AII types values 128 through 201 254 are reserved for vendor proprietary extensions and are to be 202 assigned by IANA, using the "First Come First Served" policy defined 203 in [RFC2434]. 205 Any assignments requested from this registry require a description up 206 to 54 characters. 208 For each allocation a length field MUST also be specified as a 209 decimal integer. 211 Additionally, for the vendor proprietary extensions range a citation 212 of a person or company name is also required. A document reference 213 should also be provided. 215 Initial Attachment Individual Identifier (AII) Type allocations are 216 specified below: 218 AII Type Length Description Reference 219 0x01 4 A 32 bit unsigned number local identifier. [SIG] 221 3.4.2. Attachment Group Identifier (AGI) Type 223 IANA needs to set up a registry of "Attachment Group Identifier (AGI) 224 Type". These are 8-bit values. AGI Type value 1 is defined in this 225 document. AGI Type values 2 through 64 are to be assigned by IANA 226 using the "Expert Review" policy defined in [RFC2434]. AGI Type 227 values 65 through 127, and 255 are to be allocated using the IETF 228 consensus policy defined in [RFC2434]. AGI types values 128 through 229 254 are reserved for vendor proprietary extensions and are to be 230 assigned by IANA, using the "First Come First Served" policy defined 231 in [RFC2434]. 233 Any assignments requested from this registry require a description up 234 to 54 characters. 236 For each allocation a length field MUST also be specified as a 237 decimal integer. 239 Additionally, for the vendor proprietary extensions range a citation 240 of a person or company name is also required. A document reference 241 should also be provided. 243 Initial Attachment Group Identifier (AGI) Type allocations are 244 specified below: 246 AGI Type Length Description Reference 247 0x01 8 Route distinguisher (RD) [SIG] 249 3.5. Pseudo Wire Status 251 IANA needs to set up a registry of "Pseudowire Status Codes". These 252 are bit strings of length 32. Status bits 0 to 4 are defined in this 253 document. Status bits 5 to 31 are to be assigned by IANA using the 254 "Expert Review" policy defined in [RFC2434]. 256 Any requests for allocation from this registry require a description 257 up to 65 characters. 259 Initial Pseudowire Status Codes value allocations are as follows: 261 Bit MaskDescription 262 0x00000000 - Pseudo Wire forwarding (clear all failures) [CRTL] 263 0x00000001 - Pseudo Wire Not Forwarding [CRTL] 264 0x00000002 - Local Attachment Circuit (ingress) Receive Fault [CRTL] 265 0x00000004 - Local Attachment Circuit (egress) Transmit Fault [CRTL] 266 0x00000008 - Local PSN-facing PW (ingress) Receive Fault [CRTL] 267 0x00000010 - Local PSN-facing PW (egress) Transmit Fault [CRTL] 269 4. Security Considerations 271 This document specifies only fixed identifiers, and not the protocols 272 used to carry the encapsulated packets across the network. Each such 273 protocol may have its own set of security issues, but those issues 274 are not affected by the identifiers specified herein. 276 5. Full Copyright Statement 278 Copyright (C) The Internet Society (2005). 280 This document is subject to the rights, licenses and restrictions 281 contained in BCP 78, and except as set forth therein, the authors 282 retain all their rights. 284 This document and the information contained herein are provided on an 285 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 286 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 287 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 288 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 289 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 290 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 292 6. Intellectual Property Statement 294 The IETF takes no position regarding the validity or scope of any 295 Intellectual Property Rights or other rights that might be claimed to 296 pertain to the implementation or use of the technology described in 297 this document or the extent to which any license under such rights 298 might or might not be available; nor does it represent that it has 299 made any independent effort to identify any such rights. Information 300 on the procedures with respect to rights in RFC documents can be 301 found in BCP 78 and BCP 79. 303 Copies of IPR disclosures made to the IETF Secretariat and any 304 assurances of licenses to be made available, or the result of an 305 attempt made to obtain a general license or permission for the use of 306 such proprietary rights by implementers or users of this 307 specification can be obtained from the IETF on-line IPR repository at 308 http://www.ietf.org/ipr. 310 The IETF invites any interested party to bring to its attention any 311 copyrights, patents or patent applications, or other proprietary 312 rights that may cover technology that may be required to implement 313 this standard. Please address the information to the IETF at ietf- 314 ipr@ietf.org. 316 7. Normative References 318 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 319 IANA Considerations section in RFCs", BCP 26, RFC 2434, October 320 1998. 322 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 323 Languages", BCP 18, RFC 2277, January 1998. 325 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, March 1997. 328 [BCP79] S. Bradner, Ed., "Intellectual Property Rights in IETF 329 Technology", BCP 79, RFC 3979, March 2005. 331 [BCP78] S. Bradner, Ed., "IETF Rights in Contributions", 332 BCP 78, RFC 3978, March 2005. 334 8. Informative References 336 [CRTL] "Pseudowire Setup and Maintenance using LDP", 337 Martini, L., et al., draft-ietf-pwe3-control-protocol-16.txt, 338 April 2005. (work in progress) 340 [VCCV] T. D. Nadeau, R. Aggarwal, "Pseudo Wire Virtual Circuit 341 Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-07.txt, 342 August 2005. (work in progress) 344 [FRAG] Andrew G. Malis, W. Mark Townsley, "PWE3 Fragmentation 345 and Reassembly", draft-ietf-pwe3-fragmentation-09.txt, 346 September 2005. (work in progress) 348 [FCS] Andrew G. Malis, David Allan, Nick Del Regno, "PWE3 Frame 349 Check Sequence Retention", draft-ietf-pwe3-fcs-retention-04.txt, 350 September 2005. (work in progress) 352 [CEP] "SONET/SDH Circuit Emulation Service Over Packet (CEP)", 353 draft-ietf-pwe3-sonet-11.txt (work in progress) 355 [SAToP] "Structure-Agnostic TDM over Packet (SAToP)", 356 draft-ietf-pwe3-satop-03.txt (work in progress) 358 [FRAME] "Frame Relay over Pseudo-Wires", 359 draft-ietf-pwe3-frame-relay-02.txt (work in progress ) 361 [ATM] "Encapsulation Methods for Transport of ATM Cells/Frame Over IP 362 and MPLS Networks", draft-ietf-pwe3-atm-encap-05.txt (work in 363 progress) 365 [PPPHDLC] "Encapsulation Methods for Transport of PPP/HDLC Frames 366 Over IP and MPLS Networks", 367 draft-ietf-pwe3-hdlc-ppp-encap-05.txt (work in progress) 369 [ETH] "Encapsulation Methods for Transport of Ethernet Frames Over 370 IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-06.txt. 371 (work in progress) 373 [CESoPSN] A.Vainshtein et al, "TDM Circuit Emulation Service 374 over Packet Switched Network (CESoPSN)", Work in Progress, 375 July 2005, draft-ietf-pwe3-cesopsn-03.txt (work in progress) 377 [TDMoIP] Y. Stein, "TDM over IP", February 2005, 378 draft-ietf-pwe3-tdmoip-04.txt (work in progress). 380 [RFC1144] V. Jacobson, "Compressing TCP/IP Headers for 381 Low-Speed Serial Links", RFC 1144, February 1990. 383 [RFC2507] M. Degermark, B. Nordgren, S. Pink, "IP Header 384 Compression", rfc 2507, February 1999. 386 [RFC2508] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP 387 Headers for Low-Speed Serial Links' 389 [RFC3032] E. Rosen, et al., "MPLS Label Stack Encoding" 390 RFC 3032, January 2001. 392 [RFC3095] C. Bormann, Ed. "RObust Header Compression (ROHC): 393 Framework and four profiles: RTP, UDP, ESP, and uncompressed", 394 RFC 3095, July 2001. 396 [RFC3545] T. Koren, et al., "Enhanced Compressed RTP (CRTP) 397 for Links with High Delay, Packet Loss and Reordering", 398 RFC 3545, July 2003. 399 [SIG] E. Rosen, W. Luo, B. Davie, "Provisioning, Autodiscovery, 400 and Signaling in L2VPNs", draft-ietf-l2vpn-signaling-06.txt, 401 September 2005. (work in progress) 403 9. Author Information 405 Luca Martini 406 Cisco Systems, Inc. 407 9155 East Nichols Avenue, Suite 400 408 Englewood, CO, 80112 409 e-mail: lmartini@cisco.com