idnits 2.17.1 draft-ietf-pwe3-iana-allocation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet has text resembling 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 2003) is 7621 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '8' is mentioned on line 113, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-03 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini 3 Internet Draft Level 3 Communications, LLC. 4 Expiration Date: December 2003 6 W. Mark Townsley 7 Cisco Systems 9 June 2003 11 IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3) 13 draft-ietf-pwe3-iana-allocation-01.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-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 Abstract 37 The Control and maintenance protocol for providing various Layer 1 38 and Layer 2 services over a Packet Switched Network has been 39 described in [1]. This document pre-allocates the fixed Pseudo-wire 40 identifier , and other fixed protocol values that are to be assigned 41 by IANA using the "IETF Consensus" policy defined in RFC2434 43 Table of Contents 45 1 Specification of Requirements .......................... 2 46 2 PW type ................................................ 2 47 3 Interface Parameters field ............................. 3 48 4 LDP Status codes ....................................... 3 49 5 Pseudo Wire Status ..................................... 4 50 6 Security Considerations ................................ 4 51 7 Intellectual Property Disclaimer ....................... 4 52 8 References ............................................. 4 53 9 Author Information ..................................... 5 55 1. Specification of Requirements 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC 2119 61 2. PW type 63 As specified in [1], a Virtual Circuit FEC element contains the PW 64 Type field. PW Type value 0 is reserved. PW Type values 1 through 16 65 are defined in this document. PW Type values 17 through 63 are to be 66 assigned by IANA using the "IETF Consensus" policy defined in 67 RFC2434. PW Type values 64 through 127 are to be assigned by IANA, 68 using the "First Come First Served" policy defined in RFC2434. VC 69 Type values 128 through 32767 are vendor-specific, and values in this 70 range are not to be assigned by IANA. 72 The PW Type is 15 bit quantity containing a value which represents 73 the type of PW. Assigned Values are: 75 PW type Description 77 0x0001 Frame Relay DLCI 78 0x0002 ATM AAL5 SDU VCC transport 79 0x0003 ATM transparent cell transport 80 0x0004 Ethernet Tagged Mode 81 0x0005 Ethernet 82 0x0006 HDLC 83 0x0007 PPP 84 0x0008 SONET/SDH Circuit Emulation Service Over MPLS (CEM) [8] 85 0x0009 ATM n-to-one VCC cell transport 86 0x000A ATM n-to-one VPC cell transport 87 0x000B IP Layer2 Transport 88 0x000C ATM one-to-one VCC Cell Mode 89 0x000D ATM one-to-one VPC Cell Mode 90 0x000E ATM AAL5 PDU VCC transport 91 0x000F Frame-Relay Port mode 92 0x0010 SONET/SDH Circuit Emulation over Packet (CEP) 94 3. Interface Parameters field 96 As specified in [1], a PW FEC element contains the Interface 97 Parameters field, which is a list of one or more parameters, and each 98 parameter is identified by the Parameter ID field. Parameter ID value 99 0 is reserved. Parameter ID values 1 through 9 are defined in this 100 document. Parameter ID values 10 through 63 are to be assigned by 101 IANA using the "IETF Consensus" policy defined in RFC2434. Parameter 102 ID values 64 through 127 are to be assigned by IANA, using the "First 103 Come First Served" policy defined in RFC2434. Parameter ID values 128 104 through 255 are vendor- specific, and values in this range are not to 105 be assigned by IANA. 107 The interface parameter ID is assigned as follows: 108 Parameter ID Length Description 110 0x01 4 Interface MTU in octets. 111 0x02 4 Maximum Number of concatenated ATM cells. 112 0x03 up to 82 Optional Interface Description string. 113 0x04 4 CEP [8] Payload Bytes. 114 0x05 2 CEP options. 115 0x06 2 Requested VLAN ID 116 0x07 4 CEP/TDM bit-rate 117 0x08 2 Frame-Relay DLCI Length 118 0x06 2 Fragmentation indicator 120 4. LDP Status codes 122 RFC 3036 has a range of LDP Status Code values which are assigned by 123 IANA through an IETF Consensus action. These are in the range 124 0x00000000-0x1fffffff. To meet the protocol requirements of [1], the 125 following new status codes are defined: 127 0x00000024 "Illegal C-Bit" 128 0x00000025 "Wrong C-Bit" 129 0x00000026 "Incompatible bit-rate" 131 5. Pseudo Wire Status" 133 As specified in [1], a new PW status TLV contains a 32 bit field, PW 134 status value 0 is reserved to clear all failures. PW Status Bits 0 135 through 4 are defined in this document. PW Status Bits 6 through 15 136 are to be assigned by IANA using the "IETF Consensus" policy defined 137 in RFC2434. PW Status Bits 16 through 23 are to be assigned by IANA, 138 using the "First Come First Served" policy defined in RFC2434. PW 139 Status Bits 24 through 31 are vendor-specific, and values in this 140 range are not to be assigned by IANA. 142 PW status is a 4 octet bit field as follows: 144 0x00000000 - Pseudo Wire forwarding ( clear all failures ) 145 0x00000001 - Pseudo Wire Not Forwarding 146 0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault 147 0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault 148 0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault 149 0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault 151 6. Security Considerations 153 This document specifies only fixed identifiers, and not the protocols 154 used to carry the encapsulated packets across the network. Each such 155 protocol may have its own set of security issues, but those issues 156 are not affected by the identifiers specified herein. 158 7. Intellectual Property Disclaimer 160 This document is being submitted for use in IETF standards 161 discussions. 163 8. References 165 [1] "Transport of Layer 2 Frames Over MPLS", draft-ietf-pwe3- 166 control-protocol-03.txt. ( work in progress ) 168 9. Author Information 170 Luca Martini 171 Level 3 Communications, LLC. 172 1025 Eldorado Blvd. 173 Broomfield, CO, 80021 174 e-mail: luca@level3.net 176 W. Mark Townsley 177 Cisco Systems 178 7025 Kit Creek Road 179 PO Box 14987 180 Research Triangle Park, NC 27709 181 e-mail: mark@townsley.net