path: root/doc/rfc/rfc5287.txt

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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L