doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc4385.txt b/doc/rfc/rfc4385.txt
new file mode 100644
index 0000000..7d25748
--- /dev/null
+++ b/doc/rfc/rfc4385.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                          S. Bryant
+Request for Comments: 4385                                    G. Swallow
+Category: Standards Track                                     L. Martini
+                                                           Cisco Systems
+                                                            D. McPherson
+                                                          Arbor Networks
+                                                           February 2006
+
+
+               Pseudowire Emulation Edge-to-Edge (PWE3)
+                 Control Word for Use over an MPLS PSN
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes the preferred design of a Pseudowire
+   Emulation Edge-to-Edge (PWE3) Control Word to be used over an MPLS
+   packet switched network, and the Pseudowire Associated Channel
+   Header.  The design of these fields is chosen so that an MPLS Label
+   Switching Router performing MPLS payload inspection will not confuse
+   a PWE3 payload with an IP payload.
+
+1.  Introduction
+
+   The standard MPLS encapsulations have no explicit protocol
+   identifier.  In order for a pseudowire (PW) [RFC3985] to operate
+   correctly over an MPLS packet switched network (PSN) that performs
+   MPLS payload inspection, a PW packet must not appear to a label
+   switching router (LSR) as if it were an IP packet [BCP].  An example
+   of an LSR that performs MPLS payload inspection is one that is
+   performing equal-cost multiple-path load-balancing (ECMP) [RFC2992].
+   If ECMP were performed on PW packets, the packets in the PW may not
+   all follow the same path through the PSN.  This may result in
+   misordered packet delivery to the egress PE.  The inability to ensure
+   that all packets belonging to a PW follow the same path may also
+   prevent the PW Operations and Management (OAM) [VCCV] mechanism from
+   correctly monitoring the PW.
+
+
+
+Bryant, et al.              Standards Track                     [Page 1]
+
+RFC 4385       PW3 Control Word for Use over an MPLS PSN   February 2006
+
+
+   This document specifies how the PW control word is used to
+   distinguish a PW payload from an IP payload carried over an MPLS PSN.
+   It then describes the preferred design of a PW Control Word to be use
+   over an MPLS PSN, and the Pseudowire Associated Channel Header.
+
+1.1.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2.  Avoiding ECMP
+
+   A PW that is carried over an MPLS PSN that uses the contents of the
+   MPLS payload to select the ECMP path may be subjected to packet
+   misordering [BCP].  In cases where the application using the PW is
+   sensitive to packet misordering, or where packet misordering will
+   disrupt the operation of the PW, it is necessary to prevent the PW
+   being subjected to ECMP.
+
+   All IP packets [RFC791] [RFC2460] start with a version number that is
+   checked by LSRs performing MPLS payload inspection.  To prevent the
+   incorrect processing of packets carried within a PW, PW packets
+   carried over an MPLS PSN MUST NOT start with the value 4 (IPv4) or
+   the value 6 (IPv6) in the first nibble [BCP], as those are assumed to
+   carry normal IP payloads.
+
+   This document defines a PW header and two general formats of that
+   header.  These two formats are the PW MPLS Control Word (PWMCW),
+   which is used for data passing across the PW, and a PW Associated
+   Channel Header (PWACH), which can be used for functions such as OAM.
+
+   If the first nibble of a PW packet carried over an MPLS PSN has a
+   value of 0, this indicates that the packet starts with a PWMCW.  If
+   the first nibble of a packet carried over an MPLS PSN has a value of
+   1, it starts with a PWACH.  The use of any other first nibble value
+   for a PW packet carried over an MPLS PSN is deprecated.
+
+   If a PW is sensitive to packet misordering and is being carried over
+   an MPLS PSN that uses the contents of the MPLS payload to select the
+   ECMP path, it MUST employ a mechanism that prevents packet
+   misordering.  A suitable mechanism is the PWMCW described in Section
+   3 for data, and the PWACH described in Section 5 for channel-
+   associated traffic.
+
+   The PWMCW or the PWACH MUST immediately follow the bottom of the MPLS
+   label stack.
+
+
+
+
+Bryant, et al.              Standards Track                     [Page 2]
+
+RFC 4385       PW3 Control Word for Use over an MPLS PSN   February 2006
+
+
+3.  Generic PW MPLS Control Word
+
+   The Generic PW MPLS Control Word (PWMCW) is shown in Figure 1.
+
+    0                   1                   2                   3
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0 0 0 0|          Specified by PW Encapsulation                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+         Figure 1: Generic PW MPLS Control Word
+
+   The PW set-up protocol or configuration mechanism determines whether
+   a PW uses a PWMCW.  Bits 0..3 differ from the first four bits of an
+   IP packet [BCP] and hence provide the necessary MPLS payload
+   discrimination.
+
+   When a PWMCW is used, it MUST adhere to the Generic format
+   illustrated in Figure 1 above.  To provide consistency between the
+   designs of different types of PW, it SHOULD also use the following
+   preferred format:
+
+    0                   1                   2                   3
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0 0 0 0| Flags |FRG|  Length   | Sequence Number               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        Figure 2: Preferred PW MPLS Control Word
+
+   The meaning of the fields of the Preferred PW MPLS Control Word
+   (Figure 2) is as follows:
+
+   Flags (bits 4 to 7):
+
+          These bits MAY be used by for per-payload signaling.  Their
+          semantics MUST be defined in the PW specification.
+
+   FRG (bits 8 and 9):
+
+          These bits are used when fragmenting a PW payload.  Their use
+          is described in [FRAG], which is currently a work in progress.
+          When the PW is of a type that will never need payload
+          fragmentation, these bits may be used as general purpose
+          flags.
+
+
+
+
+
+
+Bryant, et al.              Standards Track                     [Page 3]
+
+RFC 4385       PW3 Control Word for Use over an MPLS PSN   February 2006
+
+
+   Length (bits 10 to 15):
+
+          When the PSN path between the PEs includes an Ethernet
+          segment, the PW packet arriving at the CE-bound PE from the
+          PSN may include padding appended by the Ethernet Data Link
+          Layer.  The CE-bound PE uses the length field to determine
+          the size of the padding added by the PSN, and hence extract
+          the PW payload from the PW packet.
+
+          If the MPLS payload is less than 64 bytes, the length field
+          MUST be set to the length of the PW payload plus the length
+          of the PWMCW.  Otherwise it MUST be set to zero.
+
+   Sequence number (Bit 16 to 31):
+
+          The sequence number implements the sequencing function
+          [RFC3985].  The use of this field is described in Section 4.
+
+4.  Sequencing
+
+   The sequence number mechanism is PW specific.  The PW encapsulation
+   specification MAY define a sequence number mechanism to be used, or
+   it may indicate that the mechanism described here is to be used.  A
+   pseudo-code description of this mechanism is given in the non-
+   normative Appendix.
+
+   The sequence number mechanism described here uses a circular unsigned
+   16-bit number space that excludes the value zero.
+
+4.1.  Setting the Sequence Number
+
+   For a given PW, and a pair of routers PE1 and PE2, if PE1 supports
+   packet sequencing and packet sequencing is enabled for the PW, then
+   the following procedures MUST be used:
+
+     o The initial packet transmitted on the PW MUST be sent with
+       sequence number one.
+
+     o Subsequent packets MUST increment the sequence number by one for
+       each packet.
+
+     o The sequence number that follows 65535 (maximum unsigned 16-bit
+       number) is one.
+
+   If the transmitting router PE1 does not support sequence number
+   processing, or packet sequencing is disabled, then the sequence
+   number field in the control word MUST be set to zero for all packets
+   transmitted on the PW.
+
+
+
+Bryant, et al.              Standards Track                     [Page 4]
+
+RFC 4385       PW3 Control Word for Use over an MPLS PSN   February 2006
+
+
+4.2.  Processing the Sequence Number
+
+   If a router PE2 supports receive sequence number processing, and
+   packet sequencing is enabled for this PW, then the following
+   procedure is used:
+
+   When a PW is initially set up, the "expected sequence number"
+   associated with it MUST be initialized to one.
+
+   When a packet is received on that PW, the sequence number SHOULD be
+   processed as follows:
+
+     o If the sequence number on the packet is zero, the sequence
+       integrity of the packets cannot be determined.  In this case, the
+       received packet is considered to be in order.
+
+     o Otherwise if the packet sequence number equals the expected
+       sequence number, the packet is in order.
+
+     o Otherwise if the packet sequence number is greater than the
+       expected sequence number, and the packet sequence number minus
+       the expected sequence number is less than 32768, the packet is
+       within the allowed receive sequence number window.  The
+       implementation MAY treat the packet as in order.
+
+     o Otherwise if the packet sequence number is less than the expected
+       sequence number and the expected sequence number minus the packet
+       sequence number is greater than or equal to 32768, the packet is
+       within the allowed receive sequence number window.  The
+       implementation MAY treat the packet as in order.
+
+     o Otherwise the packet is out of order.
+
+   If the packet is found to be in order, it MAY be delivered
+   immediately.
+
+   If the packet sequence number was not zero, then the expected
+   sequence number is set to the packet sequence number plus one.  The
+   expected sequence number that follows 65535 (maximum unsigned 16-bit
+   number) is one.
+
+   Packets that are received out of order MAY either be dropped or
+   reordered.  The choice between dropping or reordering an out-of-
+   sequence packet is at the discretion of the receiver.
+
+   If a PE negotiated not to use receive sequence number processing, and
+   it received a non-zero sequence number, then it SHOULD send a PW
+   status message indicating a receive fault, and disable the PW.
+
+
+
+Bryant, et al.              Standards Track                     [Page 5]
+
+RFC 4385       PW3 Control Word for Use over an MPLS PSN   February 2006
+
+
+5.  PW Associated Channel
+
+   For some PW features, an associated channel is required.  An
+   associated channel is a channel that is multiplexed in the PW with
+   user traffic, and thus follows the same path through the PSN as user
+   traffic.  Note that the use of the term "channel" is not a "PW
+   channel type" as used in subsection 5.1.2 of [RFC3985].
+
+   When MPLS is used as the PSN, the PW Associated Channel (PWAC) is
+   identified by the following header:
+
+   0                   1                   2                   3
+   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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0 0 0 1|Version|   Reserved    |         Channel Type          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       Figure 3: PW Associated Channel Header
+
+   The meanings of the fields in the PW Associated Channel Header
+   (PWACH) (Figure 3) are:
+
+   Version:
+
+          This is the version number of the PWACH.  This specification
+          defines version 0.
+
+   Reserved:
+
+          MUST be sent as 0, and ignored on reception.
+
+   Channel Type:
+
+          The PW Associated Channel Type is defined in the IANA PW
+          Associated Channel Type registry [IANA].
+
+   Bits 0..3 MUST be 0001.  This allows the packet to be distinguished
+   from an IP packet [BCP] and from a PW data packet.
+
+6.  IANA Considerations
+
+   IANA has set up a registry of "Pseudowire Associated Channel Types".
+   These are 16-bit values.  Registry entries are assigned by using the
+   "IETF Consensus" policy defined in [RFC2434].  The value 0x21
+   indicates that the Associated Channel carries an IPv4 packet.  The
+   value 0x57 indicates that the Associated Channel carries an IPv6
+   packet.
+
+
+
+
+Bryant, et al.              Standards Track                     [Page 6]
+
+RFC 4385       PW3 Control Word for Use over an MPLS PSN   February 2006
+
+
+7.  Security Considerations
+
+   An application using a PW Associated Channel must be aware that the
+   channel can potentially be misused.  Any application using the
+   Associated Channel MUST therefore fully consider the resultant
+   security issues, and provide mechanisms to prevent an attacker from
+   using this as a mechanism to disrupt the operation of the PW or the
+   PE, and to stop this channel from being used as a conduit to deliver
+   packets elsewhere.  The selection of a suitable security mechanism
+   for an application using a PW Associated Channel is outside the scope
+   of this document.
+
+   If a PW has been configured to operate without a CW, the PW
+   Associated Channel Type mechanism described in the document MUST NOT
+   be used.  This is to prevent user payloads being fabricated in such a
+   way that they mimic the PW Associated Channel Header, and thereby
+   provide a method of attacking the application that is using the
+   Associated Channel.
+
+8.  Acknowledgements
+
+   The authors wish to thank David Allan, Thomas Nadeau, Yaakov Stein,
+   and Mark Townsley for their input to this work.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryant, et al.              Standards Track                     [Page 7]
+
+RFC 4385       PW3 Control Word for Use over an MPLS PSN   February 2006
+
+
+9.  Normative References
+
+   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791, September
+              1981.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, December 1998.
+
+10.  Informative References
+
+   [BCP]      Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
+              Cost Multipath Treatment in MPLS Networks", Work in
+              Progress, September 2005.
+
+   [FRAG]     Malis, A. and M. Townsley, "PWE3 Fragmentation and
+              Reassembly", Work in Progress, November 2005.
+
+   [IANA]     Martini, L., "IANA Allocations for Pseudowire Edge to Edge
+              Emulation (PWE3)", Work in Progress, November 2005.
+
+   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   [RFC2992]  Hopps, C., "Analysis of an Equal-Cost Multi-Path
+              Algorithm", RFC 2992, November 2000.
+
+   [RFC3985]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
+              Edge (PWE3) Architecture", RFC 3985, March 2005.
+
+   [VCCV]     Nadeau, T. and R. Aggarwal, "Pseudowire Virtual Circuit
+              Connectivity Verification (VCCV)", Work in Progress,
+              August 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryant, et al.              Standards Track                     [Page 8]
+
+RFC 4385       PW3 Control Word for Use over an MPLS PSN   February 2006
+
+
+Appendix.  Sequence Number Processing
+
+   This appendix is non-normative.
+
+   This appendix provides a pseudo-code description of the sequence
+   number processing mechanism described in Section 4.2.
+
+   unsigned16 RECEIVED     /* packet sequence number
+   unsigned16 EXPECTED = 1 /* expected sequence number
+                           /* initialized to one
+   boolean sequencingDisabled
+   boolean dropOutOfOrder  /* policy on in-window out of sequence
+                           /* packets
+
+   updateExpected()
+   begin
+       EXPECTED := RECEIVED + 1;
+       /* Because EXPECTED is an unsigned16 it will wrap
+       /* from 65535 to 0
+       /* zero is skipped
+       if (EXPECTED = 0)
+           EXPECTED := 1;
+       return;
+   end;
+
+   On receipt of a PW packet from PSN:
+   begin
+       if (RECEIVED = 0) then begin
+           processPacket();
+           return;
+       end;
+
+       if (sequencingDisabled) then begin
+           /* A packet was received with non-zero sequence number, but
+           /* sequencing is disabled
+           indicateReceiveFault();
+           disablePW();
+           return;
+       end;
+
+       /* The received sequence is the expected sequence number
+       if ((RECEIVED = EXPECTED) then begin
+           /* packet is in order
+           processPacket();
+           updateExpected();
+           return;
+       end;
+
+
+
+
+Bryant, et al.              Standards Track                     [Page 9]
+
+RFC 4385       PW3 Control Word for Use over an MPLS PSN   February 2006
+
+
+       /* Test for received sequence number is greater than
+       /* the expected sequence number and is within the
+       /* allowed receive sequence number window
+       if ((RECEIVED > EXPECTED) and
+           ((RECEIVED - EXPECTED) < 32768) then begin
+           /* packet is in the window, but there are late/missing
+           /* packets
+           if (dropOutOfOrder) then begin
+               /* policy is to receive immediately, dropping
+               /* out of sequence packets
+               processPacket();
+               updateExpected();
+               return;
+           end else begin
+               /* policy is to wait for late packets
+               processMissingPackets();
+               return;
+           end;
+       end;
+
+       /* Test for the received sequence is less than the
+       /* expected sequence number and is within the allowed
+       /* receive sequence number window
+       if ((RECEIVED < EXPECTED) and
+           ((EXPECTED - RECEIVED) >= 32768) then begin
+           /* packet is in the window, but there are late/missing
+           /* packets
+
+
+           if (dropOutOfOrder) then begin
+               /* policy is to receive immediately, dropping
+               /* out of sequence packets
+               processPacket();
+               updateExpected();
+               return;
+           end else begin
+               /* policy is to wait for late packets
+               processMissingPackets();
+               return;
+           end;
+       end;
+
+       /* Received packet was outside the allowed receive
+       /* sequence number window
+       processOutOfWindow();
+   end;
+
+
+
+
+
+Bryant, et al.              Standards Track                    [Page 10]
+
+RFC 4385       PW3 Control Word for Use over an MPLS PSN   February 2006
+
+
+Authors' Addresses
+
+   Stewart Bryant
+   Cisco Systems,
+   250, Longwater,
+   Green Park,
+   Reading, RG2 6GB,
+   United Kingdom.
+
+   EMail: stbryant@cisco.com
+
+
+   George Swallow
+   Cisco Systems, Inc.
+   1414 Massachusetts Ave
+   Boxborough, MA 01719
+
+   EMail:  swallow@cisco.com
+
+
+   Luca Martini
+   Cisco Systems, Inc.
+   9155 East Nichols Avenue, Suite 400
+   Englewood, CO, 80112
+
+   EMail: lmartini@cisco.com
+
+
+   Danny McPherson
+   Arbor Networks, Inc.
+
+   EMail: danny@arbor.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryant, et al.              Standards Track                    [Page 11]
+
+RFC 4385       PW3 Control Word for Use over an MPLS PSN   February 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Bryant, et al.              Standards Track                    [Page 12]
+