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

Versions: (draft-vainshtein-pwe3-tdm-control-protocol-extensi) 00 01 02 03 04 05 06 07 RFC 5287

     Network Working Group               A. Vainshtein (Axerra Networks)
     Internet Draft                 Y(J) Stein (RAD Data Communications)

     Expiration Date:
     September 2006


                                                              March 2006

         Control Protocol Extensions for Setup of TDM Pseudowires

           draft-ietf-pwe3-tdm-control-protocol-extensi-01.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 defines extension to the PWE3 control protocol [PWE3-
 CONTROL] and PWE3 IANA allocations [PWE3-IANA] required for setup of
 TDM pseudo wires.













Vainshtein and Stein    Standards Track                  [Page 1]

 Control Protocol Extensions for Setup of TDM Pseudo wires   March 2006

 TABLE OF CONTENTS

 1. Introduction......................................................2
 2. PW FEC for Setup of TDM PWs.......................................2
 3. Interface Parameters for TDM PWs..................................3
   3.1. CEP/TDM Payload Bytes (0x04)..................................3
   3.2. CEP/TDM Bit-Rate (0x07).......................................4
   3.3. Number of TDMoIP AAL1 cells per packet (0x0D - subject to IANA
   approval)..........................................................4
   3.4. TDMoIP AAL1 mode (0x0E - subject to IANA approval)............5
   3.5. TDMoIP AAL2 Options (0x0F - subject to IANA approval).........5
   3.6. Fragmentation Indicator (0x09)................................6
   3.7. TDM Options (0x0B)............................................6
 4. Extending CESoPSN Basic NxDS0 Services with CE Application
 Signaling............................................................8
 5. LDP Status Codes..................................................9
 6. Using the PW Status TLV...........................................9
 7. IANA Considerations..............................................10
 8. Security Considerations..........................................10
 9. Acknowledgements.................................................10
 10. Disclaimer of Validity..........................................10
 11. Normative References............................................11
 12. Informational References........................................11


 1. Introduction

 This document defines extension to the PWE3 control protocol [PWE3-
 CONTROL] and PWE3 IANA allocations [PWE3-IANA] required for setup of
 TDM pseudo wires.

 Structure-agnostic TDM pseudo wires have been specified in [PWE3-SAToP]
 and structure-aware ones in [PWE3-CESoPSN] and [PWE3-TDMoIP].

 [PWE3-CONTROL] defines extensions to LDP [RFC3036] that are required to
 exchange PW labels for PWs emulating various Layer 2 services
 (Ethernet, FR, ATM, HDLC etc.). Setup of TDM PWs requires both
 interpretation of the existing information elements of these extensions
 and exchange of additional information.

 Setup of TDM PWs using L2TPv3 will be defined in a separate document.

 Status of attachment circuits of TDM PWs can be exchanged between the
 terminating PEs using the mechanism defined in [PWE3-CONTROL] and
 [SHAH-PWE3-CONTROL-EXT] without any changes. However, usage of these
 mechanisms with TDM PWs is NOT RECOMMENDED since indication of status
 of the TDM attachment circuits is carried in-band in the data plane.

 2. PW FEC for Setup of TDM PWs

 [PWE3-CONTROL] uses LDP Label Mapping message [RFC3036] for advertising
 the FEC-to-PW Label binding, and defines two types of PW FEC that can
 be used for this purpose:

Vainshtein and Stein       Expires   September 2006            [Page 2]

 Control Protocol Extensions for Setup of TDM Pseudo wires   March 2006



 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
     e) Interface parameters
 2. Generalized PW FEC (FEC 129). This FEC contains only:
     a) PW type
     b) Control bit
     c) AGI, SAII and 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.

 Both types of PW FEC MAY be used for setup of TDM PWs with appropriate
 selection of PW types and interface parameters.


 The PW Types for TDM PWs are allocated in [PWE3-IANA] as follows:

 o  0x0011  Structure-agnostic E1 over Packet [PWE3-SAToP]
 o  0x0012  Structure-agnostic T1 (DS1) over Packet [PWE3-SAToP]
 o  0x0013  Structure-agnostic E3 over Packet [PWE3-SAToP]
 o  0x0014  Structure-agnostic T3 (DS3) over Packet [PWE3-SAToP]
 o  0x0015  CESoPSN basic mode [PWE3-CESoPSN]
 o  0x0016  TDMoIP AAL1 mode [PWE3-TDMoIP]
 o  0x0017  CESoPSN TDM with CAS [PWE3-CESoPSN]
 o  0x0018  TDMoIP AAL2 mode [PWE3-TDMoIP]

 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.

 3. Interface Parameters for TDM PWs
    3.1. CEP/TDM Payload Bytes (0x04)

 This parameter is used for setup of all SAToP and CESoPSN PWs (i.e. PW
 types 0x0011, 0x0012, 0x0013, 0x0014, 0x0015 and 0x0017) with the
 following semantics:

 This parameter is used for setup of all SAToP and CESoPSN PWs (i.e. PW
 types 0x0011, 0x0012, 0x0013, 0x0014, 0x0015 and 0x0017) with 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,


Vainshtein and Stein       Expires   September 2006            [Page 3]

 Control Protocol Extensions for Setup of TDM Pseudo wires   March 2006

     default payload size defined for the corresponding service (see
     [PWE3-SAToP], [PWE3-CESoPSN]) 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 of a T1 trunk)
        ii)  The size of the signaling sub-structure is not accounted
           for in the specified value P.

    3.2. 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:

 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 [PWE3-SAToP]:
     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
 circuit (1,544 Mbit/s) in units of 64 kbit/s. The values mentioned
 above are used for convenience.

    3.3. Number of TDMoIP AAL1 cells per packet (0x0D - subject to
      IANA approval)

 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 should default 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 and Stein       Expires   September 2006            [Page 4]

 Control Protocol Extensions for Setup of TDM Pseudo wires   March 2006



    3.4. TDMoIP AAL1 mode (0x0E - subject to IANA approval)

 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.5. TDMoIP AAL2 Options (0x0F - subject to IANA approval)

 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    0x0F       |    Length     | V |      ENCODING             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Maximum Duration                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      CID mapping bases                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The fields in this parameter are defined as follows:

 V defines the VAD capabilities. Its values have the following
 significance:
      0 means that the CID is only switched 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.

 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
 determined by the length field. If the mapping of AAL2 CID values to
 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

Vainshtein and Stein       Expires   September 2006            [Page 5]

 Control Protocol Extensions for Setup of TDM Pseudo wires   March 2006

 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.6. Fragmentation Indicator (0x09)

 This interface parameter is specified in [PWE3-IANA] and its usage is
 explained in [PWE3-FRAG]. It MUST be omitted in the FEC of all TDM PWs
 excluding trunk-specific NxDS0 services with CAS using the CESoPSN
 encapsulation. In 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.7. TDM Options (0x0B)

 This is a new interface parameter. Its Interface Parameter ID has to be
 assigned by IANA, and its format is shown in Fig. 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


 The fields shown in this diagram are used as follows:

















Vainshtein and Stein       Expires   September 2006            [Page 6]

 Control Protocol Extensions for Setup of TDM Pseudo wires   March 2006

 Parameter ID       Identifies the TDM PW Options interface parameter,
                     value TBA by IANA
 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 end point 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 Dynamic 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 end point 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 [CESoPSN]):
                     o  '00' for PWs that do not use signaling packets
                     o  '01' for CESoPSN PWs carrying TDM data packets
                        and expecting 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
 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
                     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, 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. Value 0 means that 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 SSRC ID in the RTP header
                     expected by the PW endpoint distributing this FEC.
                     Value 0 means that SSRC ID value check will not be
                     used for detecting misconnections. Alternatively,
                     Length can be set to 8 in this case.

Vainshtein and Stein       Expires   September 2006            [Page 7]

 Control Protocol Extensions for Setup of TDM Pseudo wires   March 2006



 Notes:

 1. This interface parameter MAY be omitted in the following cases:
     a) SAToP PWs that do not use RTP header [PWE3-SAToP]
     b) Basic CESoPSN NxDS0 services without CE application signaling
        [PWE3-CESoPSN]
     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.
 2. This interface parameter MUST be present in the following cases:
     a) All TDM PWs that use RTP header
     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 Differential timestamping mode are used, the
     value of the Length field MUST be set to 8 or 12 in order to
     include at least the Timestamping Clock Frequency field in the
     value
 4. A TDM PW encapsulation MUST either use or not use RTP in both
     directions. However, it is possible to use Differential
     timestamping mode in just one direction of the PW.


 4. Extending CESoPSN Basic NxDS0 Services with CE Application
    Signaling

 [CESoPSN] defines that basic NxDS0 services can be extended to carry
 also CE application signaling (e.g., CAS) in separate signaling packets
 carried in a separate PW.

 The following rules define setup of matching pairs of CESoPSN PWs using
 the PW Id FEC and the extensions defined above:

 1. The value of PW ID for the CESoPSN PW carrying TDM data packets
     MUST be even
 2. The value of PW ID for the CESoPSN PW carrying CE application
     signaling MUST be the next odd value for the (even) value of PW ID
     for the CESoPSN PW carrying TDM data packets
 3. The two PWs MUST:
     a) Have the same PW Type
     b) Have the same values of all the Interface Parameters with the
        exception of the code point in the SP field of the TDM Options
        parameter.
        i)   The PWId FEC of the PW carrying TDM data packets must be
           marked with SP bits set to '01' in this field
        ii)  The PWId FEC of the PW carrying CE signaling packets must
           be marked with SP bits set to '10' in this field.


Vainshtein and Stein       Expires   September 2006            [Page 8]

 Control Protocol Extensions for Setup of TDM Pseudo wires   March 2006

 If only one of the two PWs required to carry a CESoPSN basic NxDS0
 service and associated CE signaling packets has been established and
 the other one failed, the established PW MUST be torn down.

 Setup of CESoPSN PWs with CE application signaling using the
 Generalized PW FEC is left for further study.


 5. LDP Status Codes

 In addition to the status codes defined in section 5.3 of [PWE3-
 CONTROL], the following status codes defined in [PWE3-IANA] MUST be
 used to indicate the reason of failure to establish a TDM PW:

 1. Incompatible bit rate:
     a) In the case of mismatch of T1 encapsulation modes (basic vs.
        octet-aligned)
     b) In case of mismatch in the number of timeslots for NxDS0 basic
        services or trunk-specific NxDS0 services with CAS
 2. CEP/TDM mis-configuration:
     a) In the case of mismatch in the desired usage of RTP header
     b) In the case of mismatch of the desired timestamping clock
        frequency
     c) In the case of 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
     e) In the case of TDMoIP AAL1 PWs with different AAL1 modes
        specified by the end points

 In cases 2a, 2b, 2c and 2e above, the user MAY reconfigure the end
 points and attempt to setup the PW once again.

 In the case 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 control word of the TDM PWs carries both the status of their
 attachment circuits and backward indication of loss of packets (see
 [PWE3-SAToP], [PWE3-CESoPSN] and [PWE3-TDMoIP]), thus providing an
 alternative to the use of the PW Status TLV (see [PWE3-CONTROL],
 Section 5.4.2.

 However, if the PE employs separation between the data plane and
 control plane of TDM PWs, it SHOULD signal failure of the data plane of
 a TDM PW by sending to its peer a PW Status TLV for this PW with the
 status value with all of the following bits set (see [PWE3-IANA],
 Section 3.5):


Vainshtein and Stein       Expires   September 2006            [Page 9]

 Control Protocol Extensions for Setup of TDM Pseudo wires   March 2006

 o  Pseudo Wire 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.

 A typical use case for this arrangement is failure of a line card
 supporting the TWM PW interworking function (IWF).

 7. IANA Considerations

 Many of the IANA assignments required by this draft are also listed in
 [PWE3-IANA]. PW type 0x0018 is redefined here as compared to section
 2.1 of [PWE3-IANA], and needs to be redefined there in the next
 version. Assignments in sections 3.3 through 3.5 are required for three
 additional interface parameters.

 8. Security Considerations

 This draft does not have any additional impact on security of PWs above
 that of basic LDP setup of PWs.

 9. Acknowledgements

 AV thanks Sharon Galtzur for reviewing the previous version of this
 text.

 10. Disclaimer of Validity

 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 and Stein       Expires   September 2006           [Page 10]

 Control Protocol Extensions for Setup of TDM Pseudo wires   March 2006

 11. Normative References

 [RFC2119] S. Bradner, Key Words in RFCs to Indicate Requirement Levels,
 RFC 2119, IETF, 1997

 [RFC3036] L. Andersson et al, LDP Specification, RFC 3036, IETF, 2001

 [PWE3-CONTROL] L. Martini et al, Pseudowire Setup and Maintenance using
 LDP, Work in progress, June 2005, draft-ietf-pwe3-control-protocol-
 17.txt

 [PWE3-IANA] L. Martini, IANA Allocations for pseudo Wire Edge to Edge
 Emulation (PWE3), Work in progress, November 2005, draft-ietf-pwe3-
 iana-allocation-15.txt

 [PWE3-FRAG] A. Malis, M. Townsley, PWE3 Fragmentation and Reassembly,
 Work in progress, November 2005, draft-ietf-pwe3-fragmentation-10.txt

 [PWE3-SAToP] A. Vainshtein, Y. Stein, Structure-Agnostic TDM over
 Packet (SAToP), Work in Progress, February 2006, draft-ietf-pwe3-SAToP-
 05.txt


 12. Informational References


 [PWE3-CESoPSN] A. Vainshtein et al, Structure-aware TDM Circuit
 Emulation Service over Packet Switched Network (CESoPSN), Work in
 progress, November 2005, draft-ietf-pwe3-cesopsn-06.txt

 [PWE3-TDMoIP] Y(J) Stein et al, TDM over IP, Work in progress, draft-
 ietf-pwe3-tdmoip-04.txt, September 2005.

 [Q.2630.1] ITU-T Recommendation Q.2630.1, December 1999, AAL type 2
 signaling protocol - Capability set 1



















Vainshtein and Stein       Expires   September 2006           [Page 11]

 Control Protocol Extensions for Setup of TDM Pseudo wires   March 2006

 Authors' Addresses

 Alexander ("Sasha") Vainshtein
 Axerra Networks
 24 Raoul Wallenberg St.,
 Tel Aviv 69719, Israel
 email: sasha@axerra.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




 Copyright (C) The Internet Society (2006).

 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.

 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


 Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.















Vainshtein and Stein       Expires   September 2006           [Page 12]


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