doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc4446.txt b/doc/rfc/rfc4446.txt
new file mode 100644
index 0000000..9773a14
--- /dev/null
+++ b/doc/rfc/rfc4446.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                         L. Martini
+Request for Comments: 4446                            Cisco Systems Inc.
+BCP: 116                                                      April 2006
+Category: Best Current Practice
+
+
+     IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)
+
+Status of This Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document allocates the fixed pseudowire identifier and other
+   fixed protocol values for protocols that have been defined in the
+   Pseudo Wire Edge to Edge (PWE3) working group.  Detailed IANA
+   allocation instructions are also included in this document.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Specification of Requirements ...................................2
+   3. IANA Considerations .............................................2
+      3.1. Expert Review Directives ...................................2
+      3.2. MPLS Pseudowire Type .......................................3
+      3.3. Interface Parameters Sub-TLV Type ..........................4
+      3.4. Attachment Identifiers .....................................5
+           3.4.1. Attachment Individual Identifier Type ...............5
+           3.4.2. Attachment Group Identifier (AGI) Type ..............5
+      3.5. Pseudowire Status ..........................................6
+      3.6. PW Associated Channel Type .................................6
+   4. Security Considerations .........................................7
+   5. References ......................................................7
+      5.1. Normative References .......................................7
+      5.2. Informative References .....................................7
+
+
+
+
+
+
+
+
+
+Martini                  Best Current Practice                  [Page 1]
+
+RFC 4446               IANA Allocations for PWE3              April 2006
+
+
+1.  Introduction
+
+   Most of the new IANA registries and respective IANA-allocation
+   processes for protocols defined in the PWE3 IETF working group can be
+   found in this document.  The IANA registries defined here are in
+   general subdivided into three main ranges: a range to be allocated by
+   IETF consensus according to [RFC2434], a range to be allocated by the
+   expert review process according to [RFC2434], and a range to be
+   allocated on a first come, first served basis that is reserved for
+   vendor proprietary allocations.  Note that vendor proprietary types
+   MUST NOT be registered for IETF standards or extensions thereof,
+   whether they are still in development or already completed.
+
+2.  Specification of Requirements
+
+   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 [RFC2119].
+
+3.  IANA Considerations
+
+   IANA has created 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.
+
+3.1.  Expert Review Directives
+
+   Throughout this document, allocation procedures for several
+   registries call for an expert review process according to [RFC2434].
+   The expert should consider the following points:
+
+      *  Duplication of code point allocations should be avoided.
+
+      *  A brief, clear description of the code point allocation
+         requested should be provided.
+
+      *  The type allocation requested should be appropriate for the
+         particular requested value range in the registry.
+
+   The expert reviewing the request MUST approve or disapprove the
+   request within 10 business days from when he or she received the
+   expert review request.
+
+
+
+
+
+
+
+
+Martini                  Best Current Practice                  [Page 2]
+
+RFC 4446               IANA Allocations for PWE3              April 2006
+
+
+3.2.  MPLS Pseudowire Type
+
+   IANA has set up the registry of "MPLS Pseudowire Type".  This type
+   has 15-bit values.  PW Type values 1 through 30 are specified in this
+   document, and PW Type values 31 through 1024 are to be assigned by
+   IANA, using the "Expert Review" policy defined in [RFC2434].  PW Type
+   values 1025 through 4096 and 32767 are to be allocated using the IETF
+   consensus policy defined in [RFC2434].  PW Type values 4097 through
+   32766 are reserved for vendor-proprietary extensions and are to be
+   assigned by IANA, using the "First Come First Served" policy defined
+   in [RFC2434].  A Pseudowire Type description is required for any
+   assignment from this registry.  Additionally, for the vendor-
+   proprietary extensions range, a citation of a person or company name
+   is also required.  A document reference should also be provided.
+
+   Initial Pseudowire Type value allocations are specified below:
+
+   PW type Description                                      Reference
+   ===================================================================
+   0x0001  Frame Relay DLCI ( Martini Mode )                [FRAME]
+   0x0002  ATM AAL5 SDU VCC transport                       [ATM]
+   0x0003  ATM transparent cell transport                   [ATM]
+   0x0004  Ethernet Tagged Mode                             [ETH]
+   0x0005  Ethernet                                         [ETH]
+   0x0006  HDLC                                             [PPPHDLC]
+   0x0007  PPP                                              [PPPHDLC]
+   0x0008  SONET/SDH Circuit Emulation Service Over MPLS    [CEP]
+   0x0009  ATM n-to-one VCC cell transport                  [ATM]
+   0x000A  ATM n-to-one VPC cell transport                  [ATM]
+   0x000B  IP Layer2 Transport                              [RFC3032]
+   0x000C  ATM one-to-one VCC Cell Mode                     [ATM]
+   0x000D  ATM one-to-one VPC Cell Mode                     [ATM]
+   0x000E  ATM AAL5 PDU VCC transport                       [ATM]
+   0x000F  Frame-Relay Port mode                            [FRAME]
+   0x0010  SONET/SDH Circuit Emulation over Packet          [CEP]
+   0x0011  Structure-agnostic E1 over Packet                [SAToP]
+   0x0012  Structure-agnostic T1 (DS1) over Packet          [SAToP]
+   0x0013  Structure-agnostic E3 over Packet                [SAToP]
+   0x0014  Structure-agnostic T3 (DS3) over Packet          [SAToP]
+   0x0015  CESoPSN basic mode                               [CESoPSN]
+   0x0016  TDMoIP AAL1 Mode                                 [TDMoIP]
+   0x0017  CESoPSN TDM with CAS                             [CESoPSN]
+   0x0018  TDMoIP AAL2 Mode                                 [TDMoIP]
+   0x0019  Frame Relay DLCI                                 [FRAME]
+
+
+
+
+
+
+
+Martini                  Best Current Practice                  [Page 3]
+
+RFC 4446               IANA Allocations for PWE3              April 2006
+
+
+3.3.  Interface Parameters Sub-TLV Type
+
+   IANA has to set up the registry of "Pseudowire Interface Parameter
+   Sub-TLV types".  This type has 8-bit values.  Sub-TLV types 1 through
+   12 are specified in this document.  Sub-TLV types 13 through 64 are
+   to be assigned by IANA, using the "Expert Review" policy defined in
+   [RFC2434].  Sub-TLV types 65 through 127 and 255 are to be allocated
+   using the IETF consensus policy defined in [RFC2434].  Sub-TLV types
+   values 128 through 254 are reserved for vendor-proprietary extensions
+   and are to be assigned by IANA, using the "First Come First Served"
+   policy defined in [RFC2434].
+
+   Any assignments requested from this registry require a description of
+   up to 54 characters.
+
+   For each allocation, a length field MUST also be specified in one of
+   the following formats:
+
+      -  Text as follows:"up to X", where X is a decimal integer.
+      - Up to 3 different decimal integers.
+
+   The text "up to X" means up to and including X.
+
+   Additionally, for the vendor-proprietary extensions range, a citation
+   of a person or company name is also required.  A document reference
+   should also be provided.
+
+   Initial Pseudowire Interface Parameter Sub-TLV type allocations are
+   specified below:
+
+Parameter  Length       Description                       Reference
+ ID
+========================================================================
+ 0x01      4       Interface MTU in octets               [CRTL]
+ 0x02      4       Maximum Number of concatenated ATM cells [ATM]
+ 0x03   up to 82   Optional Interface Description string [CRTL][RFC2277]
+ 0x04      4       CEP/TDM Payload Bytes                 [CEP][TDMoIP]
+ 0x05      4       CEP options                           [CEP]
+ 0x06      4       Requested VLAN ID                     [ETH]
+ 0x07      6       CEP/TDM bit-rate                      [CEP][TDMoIP]
+ 0x08      4       Frame-Relay DLCI Length               [FRAME]
+ 0x09      4       Fragmentation indicator               [FRAG]
+ 0x0A      4       FCS retention indicator               [FCS]
+ 0x0B    4/8/12    TDM options                           [TDMoIP]
+ 0x0C      4       VCCV parameter                        [VCCV]
+
+   Note that the Length field is defined as the length of the Sub-TLV,
+   including the Sub-TLV type and length field itself.
+
+
+
+Martini                  Best Current Practice                  [Page 4]
+
+RFC 4446               IANA Allocations for PWE3              April 2006
+
+
+3.4.  Attachment Identifiers
+
+3.4.1.  Attachment Individual Identifier Type
+
+   IANA has to set up the registry of "Attachment Individual Identifier
+   (AII) Type".  This type has 8-bit values.  AII Type value 1 is
+   defined in this document.  AII Type values 2 through 64 are to be
+   assigned by IANA, using the "Expert Review" policy defined in
+   [RFC2434].  AII Type values 65 through 127 and 255 are to be
+   allocated using the IETF consensus policy defined in [RFC2434].  AII
+   types values 128 through 254 are reserved for vendor-proprietary
+   extensions and are to be assigned by IANA, using the "First Come
+   First Served" policy defined in [RFC2434].
+
+   Any assignments requested from this registry require a description of
+   up to 54 characters.
+
+   For each allocation, a length field MUST also be specified as a
+   decimal integer.
+
+   Additionally, for the vendor-proprietary extensions range, a citation
+   of a person or company name is also required.  A document reference
+   should also be provided.
+
+   Initial Attachment Individual Identifier (AII) Type allocations are
+   specified below:
+
+   AII Type     Length    Description                          Reference
+   =====================================================================
+   0x01         4         A 32 bit unsigned number local       [SIG]
+                          identifier.
+
+3.4.2.  Attachment Group Identifier (AGI) Type
+
+   IANA has to set up the registry of "Attachment Group Identifier (AGI)
+   Type".  This type has 8-bit values.  AGI Type value 1 is defined in
+   this document.  AGI Type values 2 through 64 are to be assigned by
+   IANA, using the "Expert Review" policy defined in [RFC2434].  AGI
+   Type values 65 through 127 and 255 are to be allocated using the IETF
+   consensus policy defined in [RFC2434].  AGI type values 128 through
+   254 are reserved for vendor-proprietary extensions and are to be
+   assigned by IANA, using the "First Come First Served" policy defined
+   in [RFC2434].
+
+   Any assignments requested from this registry require a description of
+   up to 54 characters.
+
+
+
+
+
+Martini                  Best Current Practice                  [Page 5]
+
+RFC 4446               IANA Allocations for PWE3              April 2006
+
+
+   For each allocation, a length field MUST also be specified as a
+   decimal integer.
+
+   Additionally, for the vendor-proprietary extensions range, a citation
+   of a person or company name is also required.  A document reference
+   should also be provided.
+
+   Initial Attachment Group Identifier (AGI) Type allocations are
+   specified below:
+
+   AGI Type     Length    Description                        Reference
+    ===================================================================
+    0x01         8         AGI encoded as Route Distinguisher [SIG]
+
+3.5.  Pseudowire Status
+
+   IANA has to set up the registry of "Pseudowire Status Codes".  These
+   are bit strings of length 32.  Status bits 0 through 4 are defined in
+   this document.  Status bits 5 through 31 are to be assigned by IANA
+   using the "Expert Review" policy defined in [RFC2434].
+
+   Any requests for allocation from this registry require a description
+   of up to 65 characters.
+
+   Initial Pseudowire Status Code value allocations are as follows:
+
+   Bit Mask     Description
+   ====================================================================
+   0x00000000 - Pseudowire forwarding (clear all failures)       [CRTL]
+   0x00000001 - Pseudowire Not Forwarding                        [CRTL]
+   0x00000002 - Local Attachment Circuit (ingress) Receive Fault [CRTL]
+   0x00000004 - Local Attachment Circuit (egress) Transmit Fault [CRTL]
+   0x00000008 - Local PSN-facing PW (ingress) Receive Fault      [CRTL]
+   0x00000010 - Local PSN-facing PW (egress) Transmit Fault      [CRTL]
+
+   For the definition of the "PW Associated Channel Type" please refer
+   to [RFC4385].
+
+3.6 PW Associated Channel Type
+
+   For the definition of the "PW Associated Channel Type", please refer
+   to [RFC4385].
+
+
+
+
+
+
+
+
+
+Martini                  Best Current Practice                  [Page 6]
+
+RFC 4446               IANA Allocations for PWE3              April 2006
+
+
+4.  Security Considerations
+
+   This document specifies only fixed identifiers, and not the protocols
+   used to carry the encapsulated packets across the network.  Each such
+   protocol may have its own set of security issues, but those issues
+   are not affected by the identifiers specified herein.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+             October 1998.
+
+   [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
+             Languages", BCP 18, RFC 2277, January 1998.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+5.2.  Informative References
+
+   [CRTL]    Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
+             G. Heron, "Pseudowire Setup and Maintenance Using the Label
+             Distribution Protocol (LDP)", RFC 4447, April 2006.
+
+   [VCCV]    Nadeau, T. and R. Aggarwal, "Pseudo Wire Virtual Circuit
+             Connectivity Verification (VCCV)", Work in Progress, August
+             2005.
+
+   [FRAG]    Malis, A. and M. Townsley, "PWE3 Fragmentation and
+             Reassembly", Work in Progress, September 2005.
+
+   [FCS]     Malis, A., Allan, D., and N. Del Regno, "PWE3 Frame Check
+             Sequence Retention", Work in Progress, September 2005.
+
+   [CEP]     Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig,
+             "SONET/SDH Circuit Emulation Service Over Packet (CEP)",
+             Work in Progress.
+
+   [SAToP]   Vainshtein, A. Ed. and Y. Stein, Ed. "Structure-Agnostic
+             TDM over Packet (SAToP)", Work in Progress.
+
+   [FRAME]   Martini, L., Ed. and C. Kawa, "Encapsulation Methods for
+             Transport of Frame Relay Over MPLS Networks", Work in
+             Progress.
+
+
+
+
+Martini                  Best Current Practice                  [Page 7]
+
+RFC 4446               IANA Allocations for PWE3              April 2006
+
+
+   [ATM]     Martini, L., Ed., El-Aawar, N., and M. Bocci, Ed.,
+             "Encapsulation Methods for Transport of ATM Over MPLS
+             Networks", Work in Progress.
+
+   [PPPHDLC] Martini, L., Rosen, E., Heron, G. and A. Malis,
+             "Encapsulation Methods for Transport of PPP/HDLC Frames
+             Over MPLS Networks", Work in Progress.
+
+   [ETH]     Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
+             "Encapsulation Methods for Transport of Ethernet Frames
+             Over MPLS Networks", RFC 4448, April 2006.
+
+   [CESoPSN] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and
+             P. Pate, "Structure-aware TDM Circuit Emulation Service
+             over Packet Switched Network (CESoPSN)", Work in Progress.
+
+   [TDMoIP]  Stein, Y., Shashoua, R., Insler, R., and M. Anavi, "TDM
+             over IP", Work in Progress, February 2005.
+
+   [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+             Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+             Encoding", RFC 3032, January 2001.
+
+   [SIG]     Rosen, E., Luo, W., Davie, B., and V. Radoaca,
+             "Provisioning, Autodiscovery, and Signaling in L2VPNs",
+             Work in Progress, September 2005.
+
+   [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
+             "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
+             Use over an MPLS PSN", RFC 4385, February 2006.
+
+Author's Address
+
+   Luca Martini
+   Cisco Systems, Inc.
+   9155 East Nichols Avenue, Suite 400
+   Englewood, CO, 80112
+
+   EMail: lmartini@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+Martini                  Best Current Practice                  [Page 8]
+
+RFC 4446               IANA Allocations for PWE3              April 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).
+
+
+
+
+
+
+
+Martini                  Best Current Practice                  [Page 9]
+