idnits 2.17.1 draft-bryant-mcpherson-pwe3-cw-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 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 297. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 7 instances of lines with non-ascii characters in the document. == 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 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 (July 2004) is 7225 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: 'RFC2119' is mentioned on line 47, but not defined == Missing Reference: 'ARCH' is mentioned on line 51, but not defined == Missing Reference: 'BCP' is mentioned on line 183, but not defined == Missing Reference: 'VCCV' is mentioned on line 60, but not defined == Missing Reference: 'FRAG' is mentioned on line 123, but not defined == Missing Reference: 'RFC 2424' is mentioned on line 190, but not defined ** Obsolete undefined reference: RFC 2424 (Obsoleted by RFC 3803) == Unused Reference: 'RFC2424' is defined on line 245, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Downref: Normative reference to an Informational RFC: RFC 2992 ** Obsolete normative reference: RFC 2424 (Obsoleted by RFC 3803) Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bryant 3 Internet Draft Cisco Systems 4 Expiration Date: January 2005 D. McPherson 5 Arbor Networks 7 July 2004 9 PWE3 Control Word 10 draft-bryant-mcpherson-pwe3-cw-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, we certify that any applicable 15 patent or other IPR claims of which we are aware have been 16 disclosed, or will be disclosed, and any of which we become aware 17 will be disclosed, in accordance with RFC 3668. 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 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than a "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 This document describes the preferred designs of the PWE3 Control 38 Word, and the PWE3 Payload Type Identifier. The design of these 39 fields is chosen so that an MPLS LSR performing deep packet 40 inspection will not confuse a PWE3 payload with an IP payload. 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119 [RFC2119]. 48 1. Introduction 50 Packets are carried in MPLS label stacks without any protocol 51 identifier. In order for a pseudo wire (PW) [ARCH] to operate 52 correctly over an MPLS PSN that performs deep packet inspection, a 53 PW packet must not appear to the LSR as if it were an IP packet 54 [BCP]. An example of an LSR that performs deep packet inspection is 55 one that is performing equal-cost multiple-path load-balancing 56 (ECMP) [RFC2992]. If ECMP were performed on PWE3 packets, the 57 packets in the PW may not all follow the same path though the PSN. 58 This may result in misordered packet deliver to the egress PE. The 59 inability to ensure that all packets belonging to a PW follow the 60 same path also prevents the PW OAM [VCCV] mechanism from correctly 61 monitoring the PW. 63 This draft specifies how a PW Control Word distinguishes a PW MPLS 64 payload from an IP MPLS payload. 66 2. PWE3 Packet Identification 68 All IP packets [RFC791][RFC1883] start with a version number which 69 is checked by LSRs performing packet inspection. Therefore, PWE3 70 packets carried over an MPLS PSN SHOULD NOT start with the value 4 71 or the value 6 in the first nibble [BCP]. 73 A PW SHOULD employ either the generic PW Control Word described in 74 Section 3, or the PWE3 Payload Type Identifier (PWE3-PTI) described 75 in Section 4. These fields MUST immediately follow the bottom of the 76 MPLS label stack. 78 If the first nibble of a PWE3 packet carried over an MPLS PSN has a 79 value of 0, it starts with a Generic PW Control Word. If the first 80 nibble of a packet carried over an MPLS PSN has a value of 1, it 81 starts with a Payload Type Identifier. The use of any other first 82 nibble value for a PWE3 packet is deprecated. 84 3. Generic PW Control Word 86 The Generic PW Control Word is shown in Figure 1. 88 0 1 2 3 89 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 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 |0 0 0 0| Specified by PW Encapsulation | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 Figure 1: Generic PW Control Word 96 The PW set-up protocol or configuration mechanism determines whether 97 a PW uses a Control Word. Bits 0..3 differ from the first four bits 98 of an IP packet [BCP] and hence provide the necessary MPLS payload 99 discrimination. 101 When a Control Word is used, it SHOULD have the following preferred 102 form: 104 0 1 2 3 105 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 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 |0 0 0 0| Flags |FRG| Length | Sequence Number | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 Figure 2: MPLS Preferred Control Word 112 The meaning of the fields of the MPLS Preferred Control Word (Figure 113 2) are as follows: 115 Flags (bits 4 to 7): 117 These bits are available for per payload signalling. Their 118 definition is encapsulation specific. 120 FRG (bits 8 and 9): 122 These bits are used when fragmenting a PW payload. Their use 123 is defined in [FRAG]. When the PW is of a type that will 124 never need payload fragmentation, these bits may be used as 125 general purpose flags. 127 Length (bits 10 to 15): 129 The length field is used to determine the size of a PW 130 payload that might have been padded to the minimum Ethernet 131 MAC frame size during its transit across the PSN. If the 132 MPLS payload (defined as the CW + the PW payload + any 133 additional PW headers) is less than 46 bytes, the length MUST 134 be set to the length of the MPLS payload. If the MPLS 135 payload is between 46 bytes and 63 bytes the implementation 136 MAY either set to the length to the length of the MPLS 137 payload, or it MAY set it to 0. If the length of the MPLS 138 payload is greater than 63 bytes the length MUST be set to 0. 140 [Editor�s note: Both the MUSTs are needed to make the 141 mechanism work, the MAY is for backwards compatibility with 142 deployed systems] 144 Sequence number (Bit 16 to 31): 146 If the sequence number is not used, it is set to zero by the 147 sender and ignored by the receiver. Otherwise it specifies 148 the sequence number of a packet. A circular list of sequence 149 numbers is used. A sequence number takes a value from 1 to 150 65535 (2**16-1). The sequence number window size for packet 151 acceptance is dependent on the parameters of the PSN, and 152 SHOULD be configurable. The mechanism used by the 153 decapsulating PE to (re)acquire the correct sequence number 154 is implementation dependent. 156 If the payload is an OAM packet the sequence number MAY be 157 used to mark the position in the sequence, in which case it 158 has the same value as the last data PDU sent. The use of the 159 sequence number is optional for OAM payloads. 161 4. PWE3 Payload Type Identifier 163 If technical considerations result in a PW Control Word that could 164 be mistaken for an IP packet, the Control Word SHOULD be preceded by 165 a PWE3 Payload Type Identifier (PWE3-PTI). The PWE3-PTI is defined 166 follows: 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 |0 0 0 1| reserved = 0 | Payload Type | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Figure 3: PWE3 Payload Type Identifier 176 The meaning of the fields of the PWE3-PTI (Figure 3) are as follows: 178 Payload Type: 179 The PW Type as defined in the IANA PW Type registry 181 Bits 4 to 15 inclusive are reserved for future use and must be zero. 182 Bits 0..3 MUST be 0x01, and hence differ from the first four bits of 183 an IP packet [BCP]. This provides the necessary MPLS payload 184 discrimination. 186 5. IANA considerations 188 This section provides guidance to the Internet Assigned Numbers 189 Authority (IANA) regarding registration of values related to the PW- 190 Type, in accordance with BCP 26 [RFC 2424]. 192 There is one namespace that requires allocation, the PW-Type value. 194 5.1 Definition of Terms 196 The following terms are used here with the meanings defined in BCP 197 26: "name space", "assigned value", "registration". 199 The following policies are used here with the meanings defined in 200 BCP 26: "Private Use", "First Come First Served", "Expert Review", 201 "Specification Required", "IETF Consensus", "Standards Action". 203 NOTE NEED TO UPDATE ABOVE ONCE SECTION IS COMPLETE 205 5.2 Recommended Registration Policies 207 For registration requests where a Designated Expert should be 208 consulted, an IESG Area Director for the Internet Area should 209 appoint the Designated Expert. 211 For registration requests requiring Expert Review, the PWE3 mailing 212 list should be consulted. 214 PW-Type codes have a range from x to y. Because a new Packet Type 215 has considerable impact on interoperability, a new PW-Type code 216 requires Standards Action, and should be allocated starting at TBD. 218 PW-Types codes have a range from x to y, and are the scarcest 219 resource in PWE3, thus they must be allocated with care. 221 PW codes k-j may be allocated following Expert Review, with 222 Specification Required. 224 The values v to x are reserved for vendor specific or experimental 225 use. 227 6. Security Considerations 229 No new security issues arise as a result of the work. 231 Normative References 233 Internet-drafts are works in progress available from 234 http://www.ietf.org/internet-drafts/ 236 [RFC791] RFC-791: DARPA Internet Program, Protocol 237 Specification, ISI, September 1981. 239 [RFC1883] RFC-1883: Internet Protocol, Version 6 (IPv6), S. 240 Deering, et al, December 1995 242 [RFC2992] RFC-2992: Analysis of an Equal-Cost Multi-Path 243 Algorithm, C. Hopps, November 2000 245 [RFC2424] RFC-2424: Guidelines for Writing an IANA 246 Considerations Section in RFCs, Alvestrand and 247 Narten, October 1998. 249 Informative References 251 Internet-drafts are works in progress available from 252 254 ARCH Bryant, S., Pate, P., "PWE3 Architecture", Internet 255 Draft, < draft-ietf-pwe3-arch-07.txt>, October 2003, 256 Work in Progress. 258 BCP Swallow, G. et al, �Avoiding Equal Cost Multipath 259 Treatment in MPLS Networks�, Internet Draft , To be published July 2004, Work in 261 Progress. 263 FRAG Malism, A., Townsley, M., �PWE3 Fragmentation and 264 Reassembly�, Internet Draft, , February 2004, Work in 266 Progress. 268 VCCV Nadeau, T., Aggarwal, T., �Pseudo Wire (PW) Virtual 269 Circuit Connection Verification (VCCV)�, Internet 270 Draft, , February 2004, 271 Work in Progress. 273 Authors' Addresses 275 Stewart Bryant 276 Cisco Systems, 277 250, Longwater, 278 Green Park, 279 Reading, RG2 6GB, 280 United Kingdom. Email: stbryant@cisco.com 282 Danny McPherson 283 Arbor Networks Email: danny@arbor.net 285 Full copyright statement 287 Copyright (C) The Internet Society (2004). This document is subject 288 to the rights, licenses and restrictions contained in BCP 78, and 289 except as set forth therein, the authors retain all their rights. 291 This document and the information contained herein are provided on 292 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 293 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 294 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 295 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 296 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 297 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.