GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:bcp:bcp116

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:
  1. Text as follows:"up to X", where X is a decimal integer.
  2. 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]

/data/webs/external/dokuwiki/data/pages/rfc/bcp/bcp116.txt · Last modified: 2006/04/24 23:21 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki