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.