Network Working Group                                       Luca Martini
Internet Draft
Expiration Date: May 2006                             Cisco Systems Inc.







                                                           November 2005


     IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)


                 draft-ietf-pwe3-iana-allocation-15.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document allocates the fixed Pseudo-wire identifier , and other
   fixed protocol values for protocols that have been defined in the
   pseudo wire edge to edge working group. ( PWE3 ) Detailed IANA
   allocation instructions are also included in this document.




Martini                                                         [Page 1]


Internet Draft   draft-ietf-pwe3-iana-allocation-15.txt    November 2005




Table of Contents

    1      Specification of Requirements  ..........................   2
    2      Introduction  ...........................................   2
    3      IANA Considerations  ....................................   3
    3.1    Expert Review Directives  ...............................   3
    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  .................   6
    3.5    Pseudo Wire Status  .....................................   6
    4      Security Considerations  ................................   7
    5      Full Copyright Statement  ...............................   7
    6      Intellectual Property Statement  ........................   7
    7      Normative References  ...................................   8
    8      Informative References  .................................   8
    9      Author Information  .....................................  10





1. 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]


2. 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 in a first come first served basis reserved for vendor
   proprietary allocations. It should be noted that vendor proprietary
   types MUST NOT be registered for IETF standards or extensions of
   those, whether still in development or already completed.







Martini                                                         [Page 2]


Internet Draft   draft-ietf-pwe3-iana-allocation-15.txt    November 2005


3. IANA Considerations

   IANA is requested to create 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:

     * Avoid Duplication of code point allocations.
     * A brief clear description of the code point allocation requested.
     * Whether the type allocation requested is appropriate for the
       particular requested value range in the registry.

   The Expert reviewing the request MUST provide an answer, approving,
   or disapproving the request within 10 business days from when the he
   or she received the expert review request.


3.2. MPLS Pseudowire Type

   IANA needs to set up a registry of "MPLS Pseudowire Type". These are
   15-bit values. PW Type values 1 through 30 are specified in this
   document, 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]



Martini                                                         [Page 3]


Internet Draft   draft-ietf-pwe3-iana-allocation-15.txt    November 2005


   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]


3.3. Interface Parameters Sub-TLV type

   IANA needs to set up a registry of "Pseudowire Interface Parameter
   Sub-TLV types". These are 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 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" is meant to mean 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



Martini                                                         [Page 4]


Internet Draft   draft-ietf-pwe3-iana-allocation-15.txt    November 2005


   specified below:

   Parameter ID Length    Description    Reference
      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]
      0x04        4       CEP/TDM Payload Bytes                [CEP/TDM]
      0x05        4       CEP options                          [CEP]
      0x06        4       Requested VLAN ID                    [ETH]
      0x07        6       CEP/TDM bit-rate                     [CEP/TDM]
      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.


3.4. Attachment Identifiers

3.4.1. Attachment Individual Identifier Type

   IANA needs to set up a registry of "Attachment Individual Identifier
   (AII) Type". These are 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 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



Martini                                                         [Page 5]


Internet Draft   draft-ietf-pwe3-iana-allocation-15.txt    November 2005


   0x01         4      A 32 bit unsigned number local identifier. [SIG]


3.4.2. Attachment Group Identifier (AGI) Type

   IANA needs to set up a registry of "Attachment Group Identifier (AGI)
   Type".  These are 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 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 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 Group Identifier (AGI) Type allocations are
   specified below:

   AGI Type     Length    Description                        Reference
   0x01         8      Route distinguisher (RD)                [SIG]


3.5. Pseudo Wire Status

   IANA needs to set up a registry of "Pseudowire Status Codes". These
   are bit strings of length 32. Status bits 0 to 4 are defined in this
   document.  Status bits 5 to 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
   up to 65 characters.

   Initial Pseudowire Status Codes value allocations are as follows:

    Bit MaskDescription
   0x00000000 - Pseudo Wire forwarding (clear all failures)      [CRTL]
   0x00000001 - Pseudo Wire Not Forwarding                       [CRTL]
   0x00000002 - Local Attachment Circuit (ingress) Receive Fault [CRTL]



Martini                                                         [Page 6]


Internet Draft   draft-ietf-pwe3-iana-allocation-15.txt    November 2005


   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]


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. Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   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.


6. Intellectual Property Statement

   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.




Martini                                                         [Page 7]


Internet Draft   draft-ietf-pwe3-iana-allocation-15.txt    November 2005


   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.


7. 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] S. Bradner, "Key words for use in RFCs to Indicate
        Requirement Levels", BCP 14, RFC 2119, March 1997.

   [BCP79] S. Bradner, Ed., "Intellectual Property Rights in IETF
        Technology", BCP 79, RFC 3979, March 2005.

   [BCP78] S. Bradner, Ed., "IETF Rights in Contributions",
        BCP 78, RFC 3978, March 2005.


8. Informative References

   [CRTL] "Pseudowire Setup and Maintenance using LDP",
        Martini, L., et al., draft-ietf-pwe3-control-protocol-16.txt,
        April 2005. (work in progress)

   [VCCV] T. D. Nadeau, R. Aggarwal, "Pseudo Wire Virtual Circuit
        Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-07.txt,
        August 2005. (work in progress)

   [FRAG] Andrew G. Malis, W. Mark Townsley, "PWE3 Fragmentation
        and Reassembly", draft-ietf-pwe3-fragmentation-09.txt,
        September 2005. (work in progress)

   [FCS] Andrew G. Malis, David Allan, Nick Del Regno, "PWE3 Frame
        Check Sequence Retention", draft-ietf-pwe3-fcs-retention-04.txt,
        September 2005. (work in progress)

   [CEP] "SONET/SDH Circuit Emulation Service Over Packet (CEP)",
        draft-ietf-pwe3-sonet-11.txt (work in progress)





Martini                                                         [Page 8]


Internet Draft   draft-ietf-pwe3-iana-allocation-15.txt    November 2005


   [SAToP] "Structure-Agnostic TDM over Packet (SAToP)",
        draft-ietf-pwe3-satop-03.txt (work in progress)

   [FRAME] "Frame Relay over Pseudo-Wires",
        draft-ietf-pwe3-frame-relay-02.txt (work in progress )

   [ATM] "Encapsulation Methods for Transport of ATM Cells/Frame Over IP
        and MPLS Networks", draft-ietf-pwe3-atm-encap-05.txt (work in
        progress)

   [PPPHDLC] "Encapsulation Methods for Transport of PPP/HDLC Frames
        Over IP and MPLS Networks",
        draft-ietf-pwe3-hdlc-ppp-encap-05.txt (work in progress)

   [ETH] "Encapsulation Methods for Transport of Ethernet Frames Over
        IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-06.txt.
        (work in progress)

   [CESoPSN] A.Vainshtein et al, "TDM Circuit Emulation Service
        over Packet Switched Network (CESoPSN)", Work in Progress,
        July 2005, draft-ietf-pwe3-cesopsn-03.txt (work in progress)

   [TDMoIP] Y. Stein, "TDM over IP", February 2005,
        draft-ietf-pwe3-tdmoip-04.txt (work in progress).

   [RFC1144]  V. Jacobson, "Compressing TCP/IP Headers for
        Low-Speed Serial Links", RFC 1144, February 1990.

   [RFC2507] M. Degermark, B. Nordgren, S. Pink, "IP Header
        Compression", rfc 2507, February 1999.

   [RFC2508] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP
        Headers for Low-Speed Serial Links'

   [RFC3032] E. Rosen, et al., "MPLS Label Stack Encoding"
        RFC 3032, January 2001.

   [RFC3095] C. Bormann, Ed. "RObust Header Compression (ROHC):
        Framework and four profiles: RTP, UDP, ESP, and uncompressed",
        RFC 3095, July 2001.

   [RFC3545] T. Koren, et al., "Enhanced Compressed RTP (CRTP)
        for Links with High Delay, Packet Loss and Reordering",
        RFC 3545, July 2003.
        [SIG] E. Rosen, W. Luo, B. Davie, "Provisioning, Autodiscovery,
        and Signaling in L2VPNs", draft-ietf-l2vpn-signaling-06.txt,
        September 2005. (work in progress)




Martini                                                         [Page 9]


Internet Draft   draft-ietf-pwe3-iana-allocation-15.txt    November 2005


9. Author Information


   Luca Martini
   Cisco Systems, Inc.
   9155 East Nichols Avenue, Suite 400
   Englewood, CO, 80112
   e-mail: lmartini@cisco.com











































Martini                                                        [Page 10]