doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc5287.txt b/doc/rfc/rfc5287.txt
new file mode 100644
index 0000000..bfad30f
--- /dev/null
+++ b/doc/rfc/rfc5287.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                      A. Vainshtein
+Request for Comments: 5287                                   ECI Telecom
+Category: Standards Track                                    Y(J). Stein
+                                                 RAD Data Communications
+                                                             August 2008
+
+
+             Control Protocol Extensions for the Setup of
+     Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks
+
+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.
+
+Abstract
+
+   This document defines extension to the Pseudowire Emulation Edge-to-
+   Edge (PWE3) control protocol RFC 4447 and PWE3 IANA allocations RFC
+   4446 required for the setup of Time-Division Multiplexing (TDM)
+   pseudowires in MPLS networks.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. PW FEC for Setup of TDM PWs .....................................2
+   3. Interface Parameters for TDM PWs ................................4
+      3.1. Overview ...................................................4
+      3.2. CEP/TDM Payload Bytes ......................................5
+      3.3. CEP/TDM Bit-Rate (0x07) ....................................5
+      3.4. Number of TDMoIP AAL1 Cells per Packet .....................6
+      3.5. TDMoIP AAL1 Mode ...........................................7
+      3.6. TDMoIP AAL2 Options ........................................7
+      3.7. Fragmentation Indicator ....................................8
+      3.8. TDM Options ................................................8
+   4. Extending CESoPSN Basic NxDS0 Services with CE
+      Application Signaling ..........................................11
+   5. LDP Status Codes ...............................................12
+   6. Using the PW Status TLV ........................................13
+   7. IANA Considerations ............................................13
+   8. Security Considerations ........................................14
+   9. Acknowledgements ...............................................14
+   10. References ....................................................14
+      10.1. Normative References .....................................14
+      10.2. Informative References ...................................14
+
+
+
+Vainshtein & Stein          Standards Track                     [Page 1]
+
+RFC 5287    Control Protocol Extensions for TDM Pseudowires  August 2008
+
+
+1.  Introduction
+
+   This document defines an extension to the PWE3 control protocol
+   [RFC4447] and PWE3 IANA allocations [RFC4446] required for the setup
+   of TDM pseudowires in MPLS networks.
+
+   Structure-agnostic TDM pseudowires have been specified in [RFC4553],
+   and structure-aware ones have been specified in [RFC5086] and
+   [RFC5087].
+
+   [RFC4447] defines extensions to the Label Distribution Protocol (LDP)
+   [RFC5036] that are required to exchange PW labels for PWs emulating
+   various Layer 2 services (Ethernet, Frame Relay (FR), Asynchronous
+   Transfer Mode (ATM), High-Level Data Link Control (HDLC), etc.).  The
+   setup of TDM PWs requires both interpretation of the existing
+   information elements of these extensions and exchange of additional
+   information.
+
+   The setup of TDM PWs using L2TPv3 will be defined in a separate
+   document.
+
+   The status of attachment circuits of TDM PWs can be exchanged between
+   the terminating Provider Edges (PEs) using the PW Status mechanism
+   defined in [RFC4447] without any changes.  However, usage of this
+   mechanism is NOT RECOMMENDED for TDM PWs since the indication of the
+   status of the TDM attachment circuits is carried in-band in the data
+   plane.
+
+   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.  PW FEC for Setup of TDM PWs
+
+   [RFC4447] uses the LDP Label Mapping message [RFC5036] for
+   advertising the FEC-to-PW Label binding, and defines two types of PW
+   Forwarding Equivalence Classes (FECs) that can be used for this
+   purpose:
+
+   1. PWId FEC (FEC 128).  This FEC contains:
+
+      a) PW type
+
+      b) Control bit (indicates presence of the control word)
+
+      c) Group ID
+
+      d) PW ID
+
+
+
+Vainshtein & Stein          Standards Track                     [Page 2]
+
+RFC 5287    Control Protocol Extensions for TDM Pseudowires  August 2008
+
+
+      e) Interface parameters Sub-TLV
+
+   2. Generalized PW FEC (FEC 129).  This FEC contains only:
+
+      a) PW type
+
+      b) Control bit
+
+      c) Attachment Group Identifier (AGI), Source Attachment Individual
+         Identifier (SAII), and Target Attachment Individual Identifier
+         (TAII) that replace the PW ID
+
+   The Group ID and the Interface Parameters are contained in separate
+   TLVs, called the PW Grouping TLV and the Interface Parameters TLV.
+
+   Either of these types of PW FEC MAY be used for the setup of TDM PWs
+   with the appropriate selection of PW types and interface parameters.
+
+   The PW types for TDM PWs are allocated in [RFC4446] as follows:
+
+   o  0x0011  Structure-agnostic E1 over Packet [RFC4553]
+   o  0x0012  Structure-agnostic T1 (DS1) over Packet [RFC4553]
+   o  0x0013  Structure-agnostic E3 over Packet [RFC4553]
+   o  0x0014  Structure-agnostic T3 (DS3) over Packet [RFC4553]
+   o  0x0015  CESoPSN basic mode [RFC5086]
+   o  0x0016  TDMoIP AAL1 mode [RFC5087]
+   o  0x0017  CESoPSN TDM with CAS [RFC5086]
+   o  0x0018  TDMoIP AAL2 mode [RFC5087]
+
+   The two endpoints MUST agree on the PW type, as both directions of
+   the PW are required to be of the same type.
+
+   The Control bit MUST always be set for TDM PWs since all TDM PW
+   encapsulations always use a control word.
+
+   PW type 0x0012 MUST also be used for the setup of structure-agnostic
+   TDM PWs between a pair of J1 attachment circuits (see [RFC4805]).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vainshtein & Stein          Standards Track                     [Page 3]
+
+RFC 5287    Control Protocol Extensions for TDM Pseudowires  August 2008
+
+
+3.  Interface Parameters for TDM PWs
+
+3.1.  Overview
+
+   The interface parameters that are relevant for the setup of the TDM
+   PWs are listed below.
+
+   -------------------------------------------------------------
+   |   Interface Parameter | Sub-TLV ID | Length | Description |
+   |-----------------------|------------|--------|-------------|
+   | CEP/TDM Payload Bytes | 0x04       | 4      |Section 3.2  |
+   |-----------------------|------------|--------|-------------|
+   | CEP/TDM Bit-Rate      | 0x07       | 6      |Section 3.3  |
+   |-----------------------|------------|--------|-------------|
+   | Number of TDMoIP AAL1 | 0x0E       | 4      |Section 3.4  |
+   | Cells per Packet      |            |        |             |
+   |-----------------------|-------=----|--------|-------------|
+   | TDMoIP AAL1 Mode      | 0x10       | 4      |Section 3.5  |
+   |-----------------------|------------|--------|-------------|
+   | TDMoIP AAL2 Options   | 0x11       | 8 or   |Section 3.6  |
+   |                       |            | larger |             |
+   |                       |            |see note|             |
+   |-----------------------|------------|--------|-------------|
+   | Fragmentation         | 0x09       |  4     |Section 3.7  |
+   | Indicator             |            |        |             |
+   |-----------------------|------------|--------|-------------|
+   | TDM Options           | 0x0B       |  4, 8, |Section 3.8  |
+   |                       |            | or 12  |             |
+   -------------------------------------------------------------
+
+   If not explicitly indicated otherwise in the appropriate description,
+   the value of the interface parameter is interpreted as an unsigned
+   integer of the appropriate size (16 or 32 bits).
+
+   Note: The length of basic TDMoIP AAL2 Options interface parameter is
+   8 bytes, and when the optional Channel ID (CID) mapping bases field
+   is used, there is one additional byte for each trunk transported.
+   Thus, if 1 trunk is being supported, this message occupies 9 bytes.
+   Since there can be no more than 248 CIDs in a given PW, this can
+   never exceed 256 (this when each channel comes from a different
+   trunk).  248 channels translates to less than 9 E1s, and so, for this
+   case, the length is
+
+
+
+
+
+
+
+
+
+Vainshtein & Stein          Standards Track                     [Page 4]
+
+RFC 5287    Control Protocol Extensions for TDM Pseudowires  August 2008
+
+
+   no more than 17 bytes.  A single PE is not required to support more
+   than 10 AAL2 PWs (i.e., up to 2480 individual channels, which is more
+   than carried by a fully populated STM1).  Thus, the memory required
+   to store all the AAL2 mapping information is typically between 80 and
+   170 bytes per PE.
+
+3.2.  CEP/TDM Payload Bytes
+
+   This parameter is used for the setup of all SAToP and CESoPSN PWs
+   (i.e., PW types 0x0011, 0x0012, 0x0013, 0x0014, 0x0015, and 0x0017)
+   and employs the following semantics:
+
+   1. The two endpoints of a TDM PW MUST agree on the same value of this
+      parameter for the PW to be set up successfully.
+
+   2. Presence of this parameter in the PWId FEC or in the Interface
+      Parameters Field TLV is OPTIONAL.  If this parameter is omitted,
+      default payload size defined for the corresponding service (see
+      [RFC4553], [RFC5086]) MUST be assumed.
+
+   3. For structure-agnostic emulation, any value consistent with the
+      MTU of the underlying PSN MAY be specified.
+
+   4. For CESoPSN PWs:
+
+      a) The specified value P MUST be an integer multiple of N, where N
+         is the number of timeslots in the attachment circuit.
+
+      b) For trunk-specific NxDS0 with CAS:
+
+         i) (P/N) MUST be an integer factor of the number of frames per
+            corresponding trunk multiframe (i.e., 16 for an E1 trunk and
+            24 for a T1 or J1 trunk).
+
+        ii) The size of the signaling sub-structure is not accounted for
+            in the specified value P.
+
+   5. This parameter MUST NOT be used for the setup of TDMoIP PWs (i.e.,
+      PWs with PW types 0x0016 and 0x0018).
+
+3.3.  CEP/TDM Bit-Rate (0x07)
+
+   This interface parameter represents the bit-rate of the TDM service
+   in multiples of the "basic" 64 Kbit/s rate.  Its usage for all types
+   of TDM PWs assumes the following semantics:
+
+
+
+
+
+
+Vainshtein & Stein          Standards Track                     [Page 5]
+
+RFC 5287    Control Protocol Extensions for TDM Pseudowires  August 2008
+
+
+   1. This interface parameter MAY be omitted if the attachment circuit
+      bit-rate can be unambiguously derived from the PW type (i.e., for
+      structure-agnostic emulation of E1, E3, and T3 circuits).  If this
+      value is omitted for the structure-agnostic emulation of T1 PW
+      type, the basic emulation mode MUST be assumed.
+
+   2. If present, only the following values MUST be specified for
+      structure-agnostic emulation (see [RFC4553]:
+
+      a) Structure-agnostic E1 emulation  - 32
+
+      b) Structure-agnostic T1 emulation:
+
+         i) MUST be set to 24 in the basic emulation mode
+
+        ii) MUST be set to 25 for the "Octet-aligned T1" emulation mode
+
+      c) Structure-agnostic E3 emulation  - 535
+
+      d) Structure-agnostic T3 emulation  - 699
+
+   3. For all kinds of structure-aware emulation, this parameter MUST be
+      set to N, where N is the number of DS0 channels in the
+      corresponding attachment circuit.
+
+   Note: The value 24 does not represent the actual bit-rate of the T1
+   or J1 circuit (1,544 Mbit/s) in units of 64 kbit/s.  The values
+   mentioned above are used for convenience.
+
+   Note: A 4-byte space is reserved for this parameter for compatibility
+   with [RFC4842].
+
+3.4.  Number of TDMoIP AAL1 Cells per Packet
+
+   This parameter MAY be present for TDMoIP AAL1 mode PWs (PW type
+   0x0016) and specifies the number of 48-byte AAL1 PDUs per MPLS
+   packet.  Any values consistent with the MTU of the underlying PSN MAY
+   be specified.  If this parameter is not specified, it defaults to 1
+   PDU per packet for low bit-rates (CEP/TDM Bit-Rate less than or equal
+   to 32), and to 5 for high bit-rates (CEP/TDM Bit-Rate of 535 or 699).
+
+
+
+
+
+
+
+
+
+
+
+Vainshtein & Stein          Standards Track                     [Page 6]
+
+RFC 5287    Control Protocol Extensions for TDM Pseudowires  August 2008
+
+
+3.5.  TDMoIP AAL1 Mode
+
+   This parameter MAY be present for TDMoIP AAL1 mode PWs (PW type
+   0x0016) and specifies the AAL1 mode.  If this parameter is not
+   present, the AAL1 mode defaults to "structured".  When specified, the
+   values have the following significance:
+
+      0 - unstructured AAL1
+      2 - structured AAL1
+      3 - structured AAL1 with CAS
+
+   The two endpoints MUST agree on the TDMoIP AAL1 mode.
+
+3.6.  TDMoIP AAL2 Options
+
+   This parameter MUST be present for TDMoIP AAL2 mode PWs (PW type
+   0x0018) and has the following 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    0x11       |    Length     | V |      ENCODING             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Maximum Duration                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      CID mapping bases                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The fields in this parameter are defined as follows:
+
+   V defines the Voice Activity Detection (VAD) capabilities.  Its
+   values have the following significance:
+
+      0 means that activity is only indicated by signaling.
+      1 means that voice activity detection is employed.
+      3 means this channel is always active.  In particular, this
+        channel may be used for timing recovery.
+
+   Encoding specifies native signal processing performed on the payload.
+   When no native signal processing is performed (i.e., G.711 encoding),
+   this field MUST be zero.  Other specific values that can be used in
+   this field are beyond the scope of this specification, but the two
+   directions MUST match for the PW setup to succeed.
+
+
+
+
+
+
+
+
+Vainshtein & Stein          Standards Track                     [Page 7]
+
+RFC 5287    Control Protocol Extensions for TDM Pseudowires  August 2008
+
+
+   Maximum Duration specifies the maximum time allowed for filling an
+   AAL2 PDU, in units of 125 microseconds.  For unencoded 64 kbps
+   channels, this numerically equals the maximum number of bytes per PDU
+   and MUST be less than 64.  For other encoding parameters, larger
+   values may be attained.
+
+   CID mapping bases is an OPTIONAL parameter; its existence and length
+   are determined by the length field.  If the mapping of AAL2 CID
+   values to a physical interface and time slot is statically
+   configured, or if AAL2 switching [Q.2630.1] is employed, this
+   parameter MUST NOT appear.  When it is present, and the channels
+   belong to N physical interfaces (i.e., N E1s or T1s), it MUST be N
+   bytes in length.  Each byte represents a number to be subtracted from
+   the CID to get the timeslot number for each physical interface.  For
+   example, if the CID mapping bases parameter consists of the bytes 20
+   and 60, this signifies that timeslot 1 of trunk 1 corresponds to CID
+   21, and timeslot 1 of trunk 2 is called 61.
+
+3.7.  Fragmentation Indicator
+
+   This interface parameter is specified in [RFC4446], and its usage is
+   explained in [RFC4623].  It MUST be omitted in the FEC of all TDM PWs
+   excluding trunk-specific NxDS0 services with CAS using the CESoPSN
+   encapsulation.  In the case of these services, it MUST be present in
+   the PW FEC if the payload size specified value P differs from
+   Nx(number of frames per trunk multiframe).
+
+3.8.  TDM Options
+
+   This is a new interface parameter.  Its Interface Parameter ID (0x0B)
+   has been assigned by IANA, and its format is shown in Figure 1 below:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Parameter ID |    Length     |R|D|F|X|SP |CAS|   RSVD-1      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0|     PT      |   RSVD-2      |               FREQ            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         SSRC                                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 1.  Format of the TDM Options Interface Parameter Sub-TLV
+
+   The fields shown in this diagram are used as follows:
+
+   Parameter ID        Identifies the TDM PW Options interface
+                       parameter, 0x0B.
+
+
+
+Vainshtein & Stein          Standards Track                     [Page 8]
+
+RFC 5287    Control Protocol Extensions for TDM Pseudowires  August 2008
+
+
+   Length              4, 8, or 12 (see below).
+
+   R                   The RTP Header Usage bit: if set, indicates that
+                       the PW endpoint distributing this FEC expects to
+                       receive RTP header in the encapsulation.  RTP
+                       header will be used only if both endpoints expect
+                       to receive it.  If this bit is cleared, Length
+                       MUST be set to 4; otherwise, it MUST be either 8
+                       or 12 (see below).  If the peer PW endpoint
+                       cannot meet this requirement, the Label Mapping
+                       message containing the FEC in question MUST be
+                       rejected with the appropriate status code (see
+                       Section 4 below).
+
+   D                   The Differential timestamping Mode bit: if set,
+                       indicates that the PW endpoint distributing this
+                       FEC expects the peer to use Differential
+                       timestamping mode in the packets sent to it.  If
+                       the peer PW endpoint cannot meet this
+                       requirement, the Label Mapping message containing
+                       the FEC in question MUST be rejected with the
+                       appropriate status code (see Section 4 below).
+
+   F, X                Reserved for future extensions.  MUST be cleared
+                       when distributed and MUST be ignored upon
+                       reception.
+
+   SP                  Encodes support for the CESoPSN signaling packets
+                       (see [RFC5086]):
+
+                       o  '00' for PWs that do not use signaling packets
+
+                       o  '01' for CESoPSN PWs carrying TDM data packets
+                           and expecting Customer Edge (CE) application
+                           signaling packets in a separate PW
+
+                       o  '10' for a PW carrying CE application
+                           signaling packets with the data packets in a
+                           separate PW
+
+                       o  '11' for CESoPSN PWs carrying TDM data and CE
+                           application signaling on the same PW
+
+
+
+
+
+
+
+
+
+Vainshtein & Stein          Standards Track                     [Page 9]
+
+RFC 5287    Control Protocol Extensions for TDM Pseudowires  August 2008
+
+
+   CAS                 MUST be cleared for all types of TDM PWs
+                       excluding trunk-specific NxDS0 services with CAS.
+                       For these services, it encodes the trunk framing
+                       like the following:
+
+                          o  '01' - an E1 trunk
+
+                          o  '10' - a T1/ESF trunk
+
+                          o  '11' - a T1 SF trunk
+
+   RSVD-1 and RSVD-2   Reserved bits, which MUST be set to 0 by the PW
+                       endpoint distributing this FEC and MUST be
+                       ignored by the receiver.
+
+   PT                  Indicates the value of Payload Type in the RTP
+                       header expected by the PW endpoint distributing
+                       this FEC.  A value of 0 means that the PT value
+                       check will not be used for detecting malformed
+                       packets.
+
+   FREQ                Frequency of timestamping clock in units of 8
+                       kHz.
+
+   SSRC                Indicates the value of the Synchronization source
+                       ID (SSRC ID) in the RTP header expected by the PW
+                       endpoint distributing this FEC.  A value of 0
+                       means that the SSRC ID value check will not be
+                       used for detecting misconnections.
+                       Alternatively, Length can be set to 8 in this
+                       case.
+
+   Notes:
+
+   1. This interface parameter MAY be omitted in the following cases:
+
+      a) SAToP PWs that do not use RTP header [RFC4553].
+
+      b) Basic CESoPSN NxDS0 services without CE application signaling
+         [RFC5086].
+
+      c) TDMoIP AAL1 mode 0 or 2 PWs that do not use RTP .
+
+      d) TDMoIP AAL2 PWs that do not relay CAS signaling and do not use
+         RTP.
+
+
+
+
+
+
+Vainshtein & Stein          Standards Track                    [Page 10]
+
+RFC 5287    Control Protocol Extensions for TDM Pseudowires  August 2008
+
+
+   2. This interface parameter MUST be present in the following cases:
+
+      a) All TDM PWs that use RTP headers.
+
+      b) CESoPSN PWs that carry basic NxDS0 services and use CESoPSN
+         signaling packets to carry CE application signaling.  This case
+         is discussed in detail in Section 4 below.
+
+      c) CESoPSN PWs that carry trunk-specific NxDS0 services with CAS.
+
+      d) TDMoIP AAL1 mode 1 PWs.
+
+      e) TDMoIP AAL2 PWs that relay CAS signaling.
+
+   3. If RTP header and possibly the Differential timestamping mode are
+      used, the value of the Length field MUST be set to 8 or 12 in
+      order to accommodate the Timestamping Clock Frequency and SSRC
+      fields.
+
+   4. Usage or non-usage of the RTP header MUST match for the two
+      directions making up the TDM PW.  However, it is possible to use
+      the Differential timestamping mode in just one direction.
+
+4.  Extending CESoPSN Basic NxDS0 Services with CE Application Signaling
+
+   [RFC5086] states that basic NxDS0 services can be extended to carry
+   CE application signaling (e.g., CAS) in special signaling packets
+   carried in a separate PW.
+
+   The following rules define the setup of matching pairs of CESoPSN PWs
+   using the PW ID FEC and the extensions defined above:
+
+   1. The two PWs MUST:
+
+      a) Have the same PW type.
+
+      b) Use the same setup method (i.e., either both use the PWId FEC,
+         or both use the Generalized PW FEC).
+
+      c) Have the same values of all the Interface Parameters listed in
+         Section 3.1 above with the exception of the code point in the
+         SP field of the TDM Options parameter:
+
+         i) For the PW carrying TDM data packets, the SP bits MUST be
+            set to '01'.
+
+        ii) For the PW carrying the signaling packets, the SP bits MUST
+            set to '10'.
+
+
+
+Vainshtein & Stein          Standards Track                    [Page 11]
+
+RFC 5287    Control Protocol Extensions for TDM Pseudowires  August 2008
+
+
+   2. If the PWId FEC has been used:
+
+      a) The value of PW ID for the CESoPSN PW carrying TDM data packets
+         MUST be even.
+
+      b) The value of PW ID for the CESoPSN PW carrying CE application
+         signaling MUST be the next (odd) value after the (even) PW ID
+         of the CESoPSN PW carrying TDM data packets.
+
+   When using the Generalized PW FEC for the setup of the two PWs, no
+   specific rules for matching the two FECs are defined.
+   Implementation-specific mechanisms MAY be employed to verify the
+   proper matching of the TDM data PW with its associated CE signaling
+   PW.
+
+   If one of the two associated PWs has been established and the other
+   failed to be established, or for any reason fails after having been
+   established, the established PW MUST be torn down.
+
+5.  LDP Status Codes
+
+   In addition to the status codes defined in Sections 5.1 and 7.2 of
+   [RFC4447], the following status codes defined in [RFC4446] MUST be
+   used to indicate the reason of failure to establish a TDM PW:
+
+   1. Incompatible bit-rate:
+
+      a) In the case of a mismatch of T1 encapsulation modes (basic vs.
+         octet-aligned).
+
+      b) In the case of a mismatch in the number of timeslots for NxDS0
+         basic services or trunk-specific NxDS0 services with CAS.
+
+   2. CEP/TDM misconfiguration:
+
+      a) In the case of a mismatch in the desired usage of RTP header.
+
+      b) In the case of a mismatch of the desired Timestamping Clock
+         Frequency.
+
+      c) In the case of a mismatch of expected signaling packets
+         behavior for basic CESoPSN NxDS0 services extended to carry CE
+         application signaling in separate signaling packets.
+
+      d) In the case of trunk-specific NxDS0 services with CAS if the
+         framing types of the trunks are different.
+
+
+
+
+
+Vainshtein & Stein          Standards Track                    [Page 12]
+
+RFC 5287    Control Protocol Extensions for TDM Pseudowires  August 2008
+
+
+      e) In the case of TDMoIP AAL1 PWs with different AAL1 modes
+         specified by the endpoints.
+
+   3. The generic misconfiguration error MAY be used to indicate any
+      setup failure not covered above.
+
+   In cases 2a, 2b, 2c, and 2e above, the user MAY reconfigure the
+   endpoints and attempt to set up the PW once again.
+
+   In the case of 2d, the failure is fatal.
+
+   Note that setting of the Control bit (see Section 2 above) to zero
+   MUST result in an LDP status of "Illegal C-Bit".
+
+6.  Using the PW Status TLV
+
+   The TDM PW control word carries status indications for both
+   attachment circuits (L and M fields) and the PSN (R field) indication
+   (see [RFC4553], [RFC5086], and [RFC5087]).  Similar functionality is
+   available via use of the PW Status TLV (see Section 5.4.2 of
+   [RFC4447]).  If the latter mechanism is employed, the signaling PE
+   sends its peer a PW Status TLV for this PW, setting the appropriate
+   bits (see Section 3.5 of [RFC4446]):
+
+      o  Pseudowire Not Forwarding
+      o  Local Attachment Circuit (ingress) Receive Fault
+      o  Local Attachment Circuit (egress) Transmit Fault
+      o  Local PSN-facing PW (ingress) Receive Fault
+      o  Local PSN-facing PW (egress) Transmit Fault
+
+   As long as the TDM PW interworking function is operational, usage of
+   the Status TLV is NOT RECOMMENDED in order to avoid contention
+   between status indications reported by the data and control plane.
+   However, if the TDM PW interworking function (IWF) itself fails while
+   the PWE3 control plane remains operational, a Status TLV with all of
+   the above bits set SHOULD be sent.
+
+7.  IANA Considerations
+
+   Most of the IANA assignments required by this document are already
+   listed in [RFC4446].  Additional assignments have been made for four
+   Interface Parameter Sub-TLV types (see Section 3.1):
+
+      o  TDM Options (0x0B)
+      o  Number of TDMoIP AAL1 cells per packet (0x0E)
+      o  TDMoIP AAL1 mode (0x10)
+      o  TDMoIP AAL2 Options (0x11)
+
+
+
+
+Vainshtein & Stein          Standards Track                    [Page 13]
+
+RFC 5287    Control Protocol Extensions for TDM Pseudowires  August 2008
+
+
+8.  Security Considerations
+
+   This document does not have any additional impact on the security of
+   PWs above that of basic LDP-based setup of PWs specified in
+   [RFC4447].
+
+9.  Acknowledgements
+
+   Sharon Galtzur has reviewed one of the previous versions of this
+   document. Y. (J.) Stein would like to thank Barak Schlosser for
+   helpful discussions.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
+              "LDP Specification", RFC 5036, October 2007.
+
+   [RFC4447]  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.
+
+
+   [RFC4446]  Martini, L., "IANA Allocations for Pseudowire Edge to Edge
+              Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
+
+   [RFC4623]  Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
+              Edge (PWE3) Fragmentation and Reassembly", RFC 4623,
+              August 2006.
+
+   [RFC4553]  Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-
+              Agnostic Time Division Multiplexing (TDM) over Packet
+              (SAToP)", RFC 4553, June 2006.
+
+10.2.  Informative References
+
+   [RFC5086]  Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and
+              P. Pate, "Structure-Aware Time Division Multiplexed (TDM)
+              Circuit Emulation Service over Packet Switched Network
+              (CESoPSN)", RFC 5086, December 2007.
+
+   [RFC5087]  Y(J). Stein, Shashoua, R., Insler, R., and M. Anavi, "Time
+              Division Multiplexing over IP (TDMoIP)", RFC 5087,
+              December 2007.
+
+
+
+Vainshtein & Stein          Standards Track                    [Page 14]
+
+RFC 5287    Control Protocol Extensions for TDM Pseudowires  August 2008
+
+
+   [Q.2630.1] ITU-T Recommendation Q.2630.1, December 1999, AAL type 2
+              signaling protocol - Capability set 1
+
+   [RFC4805]  Nicklass, O., Ed., "Definitions of Managed Objects for the
+              DS1, J1, E1, DS2, and E2 Interface Types", RFC 4805, March
+              2007.
+
+   [RFC4842]  Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig,
+              "Synchronous Optical Network/Synchronous Digital Hierarchy
+              (SONET/SDH) Circuit Emulation over Packet (CEP)", RFC
+              4842, April 2007.
+
+Authors' Addresses
+
+   Alexander ("Sasha") Vainshtein
+   ECI Telecom
+   30 ha-Sivim St.,
+   PO Box 500 Petah-Tiqva, 49517 Israel
+
+   EMail: Alexander.Vainshtein@ecitele.com
+
+
+   Yaakov (Jonathan) Stein
+   RAD Data Communications
+   24 Raoul Wallenberg St., Bldg C
+   Tel Aviv  69719
+   ISRAEL
+
+   Phone: +972 3 645-5389
+   EMail: yaakov_s@rad.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vainshtein & Stein          Standards Track                    [Page 15]
+
+RFC 5287    Control Protocol Extensions for TDM Pseudowires  August 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   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, THE IETF TRUST 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Vainshtein & Stein          Standards Track                    [Page 16]
+