[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 RFC 4446

Network Working Group                                       Luca Martini
Internet Draft                                          W. Mark Townsley
Expiration Date: December 2005                        Cisco Systems Inc.







                                                               June 2005


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


                 draft-ietf-pwe3-iana-allocation-10.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

   The Control and maintenance protocol for providing various Layer 1
   and Layer 2 services over a Packet Switched Network has been
   described in [1]. This document pre-allocates the fixed Pseudo-wire
   identifier , and other fixed protocol values that are to be assigned
   by IANA using the "IETF Consensus" policy defined in RFC2434



Martini & Townsley                                              [Page 1]

Internet Draft   draft-ietf-pwe3-iana-allocation-10.txt        June 2005




Table of Contents

    1      Specification of Requirements  ..........................   2
    2      IANA Considerations  ....................................   2
    2.1    Pseudowire Type  ........................................   2
    2.2    Interface Parameters Sub-TLV type  ......................   4
    2.3    Attachment Identifiers  .................................   5
    2.3.1  Attachment Individual Identifier Type  ..................   5
    2.3.2  Attachment Group Identifier (AGI) Type  .................   5
    2.4    Pseudo Wire Status  .....................................   5
    3      Security Considerations  ................................   6
    4      Full Copyright Statement  ...............................   6
    5      Intellectual Property Statement  ........................   6
    6      Author Information  .....................................   7





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 RFC 2119


2. IANA Considerations

   Unless otherwise noted in this document, the value of 0 is reserved,
   and MUST not be used.


2.1. Pseudowire Type

   IANA needs to set up a registry of "Pseudowire Type".  These are 15-
   bit values.  PW Type values 1 through 127 are to be assigned by IANA
   using the "IETF Consensus" policy defined in RFC2434. PW Type values
   128 through 32767 are to be assigned by IANA, using the "First Come
   First Served" policy defined in RFC2434. In addition to the "First
   Come First Served" policy, an internet draft describing the intended
   use for the code point to be allocated, MUST exists at the time of
   allocation. This internet draft MAY be targeted to become an
   informational RFC, but in any case the allocation will not depend in
   any way on the status of the internet draft.  A Pseudowire Type
   description of up to 65 characters is required for any assignment
   from this registry. The registry MUST contain the name of the



Martini & Townsley                                              [Page 2]

Internet Draft   draft-ietf-pwe3-iana-allocation-10.txt        June 2005


   internet draft at the time of code point allocation.

   Initial Pseudowire type value allocations are specified below:

      PW type Description

      0x0001  Frame Relay DLCI ( Martini Mode )
      0x0002  ATM AAL5 SDU VCC transport
      0x0003  ATM transparent cell transport
      0x0004  Ethernet Tagged Mode
      0x0005  Ethernet
      0x0006  HDLC
      0x0007  PPP
      0x0008  SONET/SDH Circuit Emulation Service Over MPLS(CEM) [Note1]
      0x0009  ATM n-to-one VCC cell transport
      0x000A  ATM n-to-one VPC cell transport
      0x000B  IP Layer2 Transport
      0x000C  ATM one-to-one VCC Cell Mode
      0x000D  ATM one-to-one VPC Cell Mode
      0x000E  ATM AAL5 PDU VCC transport
      0x000F  Frame-Relay Port mode
      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
      0x0016  TDMoIP AAL1 Mode
      0x0017  CESoPSN TDM with CAS
      0x0018  TDMoIP AAL2 Mode
      0x0019  Frame Relay DLCI
      0x001A  cTCP (RFC1144) Transport Header-compressed Packets
      0x001B  IPHC (RFC2507) Transport Header-compressed Packets
      0x001C  cRTP (RFC2508) Transport Header-compressed Packets
      0x001D  ROHC (RFC3095) Transport Header-compressed Packets
      0x001E  eCRTP (RFC3545) Transport Header-compressed Packets


   Note 1: This PW type is grandfathered for a historical protocol.  The
   recommended standards-track protocol to use is CEP (PW type 0x0010).











Martini & Townsley                                              [Page 3]

Internet Draft   draft-ietf-pwe3-iana-allocation-10.txt        June 2005


2.2. Interface Parameters Sub-TLV type

   IANA needs to set up a registry of "Pseudowire Interface Parameter
   Sub-TLV types". Sub-TLV types 1 through 127 are to be assigned by
   IANA using the "IETF Consensus" policy defined in RFC2434. Sub-TLV
   types 128 through 255 are to be assigned by IANA, using the "First
   Come First Served" policy defined in RFC2434. In addition to the
   "First Come First Served" policy, an internet draft describing the
   intended use for the code point to be allocated, MUST exists at the
   time of allocation. This internet draft MAY be targeted to become an
   informational RFC, but in any case the allocation will not depend in
   any way on the status of the internet draft.  The registry MUST
   contain the name of the internet draft at the time of code point
   allocation.

   Any assignments requested from this registry require a description up
   to 54 characters. Furthermore a length specified as follows:
     - A decimal integer
     - Text as follows:"up to X", where X is a decimal integer
     - Up to 3 different decimal integers.

   is also required for assignment from this registry.

   Initial Pseudowire Interface Parameter Sub-TLV type allocations are
   specified below:
   Parameter ID Length    Description

      0x01        4       Interface MTU in octets
      0x02        4       Maximum Number of concatenated ATM cells
      0x03     up to 82   Optional Interface Description string
      0x04        4       CEP/TDM Payload Bytes
      0x05        4       CEP options
      0x06        4       Requested VLAN ID
      0x07        6       CEP/TDM bit-rate
      0x08        4       Frame-Relay DLCI Length
      0x09        4       Fragmentation indicator
      0x0A        4       FCS retention indicator
      0x0B      4/8/12    TDM options
      0x0C        4       VCCV parameter

   Note that the Length field is defined as the length of the Sub-TLV
   including the Sub-TLV type and length field itself.









Martini & Townsley                                              [Page 4]

Internet Draft   draft-ietf-pwe3-iana-allocation-10.txt        June 2005


2.3. Attachment Identifiers

2.3.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 values 1 through 127
   are to be assigned by IANA using the "IETF Consensus" policy defined
   in RFC2434. AII Type values 128 through 255 are to be assigned by
   IANA, using the "First Come First Served" policy defined in RFC2434.
   In addition to the "First Come First Served" policy, an internet
   draft describing the intended use for the code point to be allocated,
   MUST exists at the time of allocation. This internet draft MAY be
   targeted to become an informational RFC, but in any case the
   allocation will not depend in any way on the status of the internet
   draft. The registry MUST contain the name of the internet draft at
   the time of code point allocation. An AII Type description of up to
   65 characters is required for any assignment from this registry.


2.3.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 values 1 through 127 are to
   be assigned by IANA using the "IETF Consensus" policy defined in
   RFC2434. AGI Type values 128 through 255 are to be assigned by IANA,
   using the "First Come First Served" policy defined in RFC2434. In
   addition to the "First Come First Served" policy, an internet draft
   describing the intended use for the code point to be allocated, MUST
   exists at the time of allocation. This internet draft MAY be targeted
   to become an informational RFC, but in any case the allocation will
   not depend in any way on the status of the internet draft.  The
   registry MUST contain the name of the internet draft at the time of
   code point allocation. AGI Type description of up to 65 characters is
   required for any assignment from this registry.


2.4. Pseudo Wire Status

   IANA needs to set up a registry of "Pseudowire Status Codes". These
   are bitstrings of length 32. Status bits 0-23 are to be assigned by
   IANA using the "IETF Consensus" policy defined in RFC2434. PW Status
   Bits 24 through 31 are to be assigned by IANA, using the "First Come
   First Served" policy defined in RFC2434. In addition to the "First
   Come First Served" policy, an internet draft describing the intended
   use for the code point to be allocated, MUST exists at the time of
   allocation. This internet draft MAY be targeted to become an
   informational RFC, but in any case the allocation will not depend in
   any way on the status of the internet draft. The registry MUST



Martini & Townsley                                              [Page 5]

Internet Draft   draft-ietf-pwe3-iana-allocation-10.txt        June 2005


   contain the name of the internet draft at the time of code point
   allocation.  Any requests for allocation from this registry must
   include a 65 character description.  Initial Pseudowire Status Codes
   value allocations are as follows:

      0x00000000 - Pseudo Wire forwarding ( clear all failures )
      0x00000001 - Pseudo Wire Not Forwarding
      0x00000002 - Local Attachment Circuit ( ingress ) Receive Fault
      0x00000004 - Local Attachment Circuit ( egress ) Transmit Fault
      0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault
      0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault


3. 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.


4. 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.


5. 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



Martini & Townsley                                              [Page 6]

Internet Draft   draft-ietf-pwe3-iana-allocation-10.txt        June 2005


   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.

   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.


6. Author Information


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


   W. Mark Townsley
   Cisco Systems
   7025 Kit Creek Road
   PO Box 14987
   Research Triangle Park, NC 27709
   e-mail: mark@townsley.net

















Martini & Townsley                                              [Page 7]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/