wdiff rfc5611.original rfc5611.txt

TDM over L2TPv3 April 2009
Network Working Group A. Vainshtein
Internet Draft
Request for Comments: 5611 ECI Telecom
Document: draft-ietf-l2tpext-tdm-07.txt
Category: Proposed Standard S. Galtzur
Rebellion

Creation Date: April 14, 2009
Intended Status: Proposed Standard
Expires: October
July 2009

Layer Two Tunneling Protocol version 3 -
Setup of Time-Division Multiplexing (TDM) Pseudowires

Status of this Memo

Abstract

This Internet-Draft is submitted document defines extensions to IETF in full conformance with the
provisions Layer Two Tunneling Protocol
version 3 (L2TPv3) for support of BCP 78 structure-agnostic and BCP 79.

Internet-Drafts are working documents structure-
aware (Circuit Emulation Service over Packet Switched Network
(CESoPSN) style) Time-Division Multiplexing (TDM) pseudowires.
Support of structure-aware (Time-Division Multiplexing over IP
(TDMoIP) style) pseudowires over L2TPv3 is left for further study.

Status of This Memo

This document specifies an Internet standards track protocol for 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 community, and requests discussion and suggestions for a maximum
improvements. Please refer to the current edition of six months the
"Internet Official Protocol Standards" (STD 1) for the
standardization state 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 status of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

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

This Internet-Draft will expire on October 14, 2009.
this memo is unlimited.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.

Vainshtein and Galtzur Expires - October 2009 [Page 1]
TDM over L2TPv3 April 2009

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

Abstract

This document defines extensions to the Layer Two Tunneling Protocol
version 3 (L2TPv3) for support of structure-agnostic and structure-
aware (CESoPSN style) Time-Division Multiplexing (TDM) pseudowires.
Support of structure-aware (TDMoIP style) pseudowires over L2TPv3 is
left for further study.

Legal

This documents and the information contained therein 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.

Conventions used in this document

In this document we refer to control plane as the packets that
contain control information (via Attribute-Value pairs (AVP)) and the
mechanism that handles these packets.
In this document we refer to the data plane as the packets that
contain transported user data.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].

Table of Contents

1. Introduction...................................................3 Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. L2TPv3 Extension...............................................3

Vainshtein and Galtzur Expires - October 2009 [Page 2]
TDM over L2TPv3 April 2009

2.1 Extensions ...............................................3
2.1. TDM PW Attribute-Value Pair (AVP)(ICRQ, OCRQ)..............4
2.2 (AVP) (ICRQ, OCRQ) .............4
2.2. RTP Attribute-Value Pair AVP (AVP) (ICRQ, OCRQ, ICRP, OCRP).....6
2.3 OCRP) ....6
2.3. Changes in the Control Connection AVPs.....................7
2.4 Management AVPs ..........7
2.4. Changes in the Session Connection AVPs.....................7 Management AVPs .....................7
3. Creation of the TDM Pseudowire Session.........................7 Session ..........................7
4. IANA Considerations............................................8 Considerations .............................................9
5. Congestion Control.............................................9 Control ..............................................9
6. Security Considerations........................................9 Considerations ........................................10
7. Acknowledgements...............................................9 Acknowledgements ...............................................10
8. References .....................................................10
8.1. Normative references..............................................9 References ......................................10
8.2. Informative references...........................................10
Authors' Addresses...............................................10 References ....................................10

1. Introduction

This document defines extensions to the Layer Two Tunneling Protocol
Version 3(L2TPv3) 3 (L2TPv3) for support of structure-agnostic [RFC4553] and
structure-aware (CESoPSN style, see [RFC5086]) Time-Division
Multiplexing (TDM) pseudowires. Structure-agnostic encapsulation of
TDM bit-streams over L2TPv3 is described in [RFC4553], Figure 2b, and 2b;
Circuit Emulation Service over packet-Switched Packet Switched Networks (CESoPSN) (CESoPSN),
structure-aware encapsulation - is described in [RFC5086], Figures 1c
(TDM data packets) and 4a (CE application signaling packets).
However, the order of the CESoPSN Control Word (CW) and RTP header
(if it is used) MUST match between the TDM data and CE signaling
packets.

Setup of structure-aware TDM pseudowires using encapsulations
described in [RFC5087] has been left for further study.

Setup

Setup of structure-aware TDM pseudowires using the encapsulations
described in [RFC5087] has been left for further study.

Setup and maintenance of TDM pseudowires (PWs) in MPLS networks using
LDP is described in [RFC5287].

1.1. Conventions Used in This Document

In this document, we refer to the "control plane" as meaning the
packets that contain control information (via Attribute-Value Pairs
(AVPs)) and the mechanism that handles these packets. We also refer
to the "data plane" as meaning the packets that contain transported
user data.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and maintenance of TDM PWs "OPTIONAL" in MPLS networks using LDP is this
document are to be interpreted as described in [RFC5287]. RFC 2119 [RFC2119].

2. L2TPv3 Extension Extensions

The L2TPv3 Control Connection is responsible for 3 main operations:

1. Establishment and validation of a pseudowire (PW) session.

2. Ending (tearing down) of a pseudowire session.

3. Transferring of End Point status.

Tearing down of the session for a TDM pseudowire is performed
following the L2TPv3 tear-down operations as described in Section
3.4.3 of [RFC3931].

[RFC5086] and [RFC4553] describe how to transfer the Attachment
Circuit (AC) status via the data plane. Therefore Therefore, the Set-Link-Info
(SLI) message described in [RFC3931] SHOULD NOT be used for conveying
this status for the PWs in question.

Vainshtein and Galtzur Expires - October 2009 [Page 3]
TDM over L2TPv3 April 2009

[RFC3931] specifies that the Circuit Status Attribute-Value Pair
(AVP) MUST be present in the ICRQ/ICRP (Incoming-Call-Request /
Incoming-Call-Reply) messages. It also specifies that the N bit in
this AVP should be set during the PW setup setup, even if the specific AC
does not provide any way to convey the "new AC" indication.
Accordingly, the Circuit Status AVP for the PWs in question, when
used in the ICRQ/ICRP messages, MUST always have both N and A bits
set.

The next sections describe the extensions to L2TPv3 for establishment
and validation of TDM pseudowire sessions.

There are two new AVPs for the Session Management messages. One AVP
describes the TDM pseudowire attributes. The second AVP describes
the RTP attributes for this TDM pseudowire.

2.1

2.1. TDM PW Attribute-Value Pair (AVP)(ICRQ, (AVP) (ICRQ, OCRQ)

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor Id (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type (AVP-TBA-1) (99) | Reserved |SP |CAS|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit Rate | Payload Bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 0. The Length (before hiding) of this AVP is
12.

The Bit Rate field contains the value that represents the bit rate of
the local AC in the units of 64 Kbit/s Kbit/s, encoded as an unsigned 16-bit
integer. Its usage for all types of TDM PWs employs the following
semantics:

1) Only For structure-agnostic emulation, this parameter MUST be set to
one of 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 for the basic mode

ii) MUST be set to 25 for the "Octet-aligned T1" mode

c) Structure-agnostic E3 emulation - 535

d) Structure-agnostic T3 emulation - 699

2) For CESoPSN PWs PWs, this parameter MUST be set to the number of DS0
channels in the corresponding attachment circuit.

Note: For structure-agnostic T1 emulation, the values 24 and 25 do
not reflect the exact bit rate, rate and are used for convenience only.

Vainshtein and Galtzur Expires - October 2009 [Page 4]
TDM over L2TPv3 April 2009

Note: The semantics of the Bit Rate field defined above are
consistent with those of the Bit Rate Interface Attribute CEP/TDM Bit-Rate interface parameter as
defined in [RFC5287].

The Payload Bytes field contains the value representing the number of
the
TDM Payload payload bytes in the PW packet and is used with the following
semantics:

1) For structure-agnostic emulation emulation, any value of the payload
bytes Payload Bytes
can be specified.

2) For CESoPSN PWs:

a) The specified value MUST be an integer multiple of the number
of DS0 channels in the corresponding attachment circuit.

b) In addition to that, for trunk-specific NxDS0 with CAS, Channel-
Associated Signaling (CAS), the number of the trunk frames per
multiframe fragment (value resulting from the Payload Bytes
divided by the number of DS0 channels) MUST be an integer
divisor of the number of frames per corresponding trunk
multiframe.

The Reserved bits MUST be set to 0 on transmission and MUST be
ignored on reception.

The SP bits define support for the CESoPSN application CESoPSN-application signaling
packets (see [RFC5086]) and MUST be used as following: follows:

1) Set to '01' for the CESoPSN PWs carrying TDM data packets and
expecting CE application signaling packets in a separate PW PW.

2) Set to '10' for a PW carrying CE application signaling packets
with the data packets in a separate PW PW.

3) Set to '11' for e a CESoPSN PW carrying both TDM data and signaling packets
packets.

4) Set to '00' for SAToP Structure-Agnostic Time-Division Multiplexing over
Packet (SAToP) PWs and for CESoPSN PWs not using separate
signaling packets.

The CAS bits define the trunk type for trunk-specific CESoPSN
services with CAS. These bits:
1) For trunk-specific CESoPSN with CAS these bits MUST be set to:

1) For trunk-specific CESoPSN with CAS:

a) '01' in the case of an E1 trunk

b) '10' in the case of a T1/ESF trunk

c) '11' in the case of a T1/SF trunk. trunk
2) MUST be set to '00' for all the other TDM pseudowire types.

Vainshtein and Galtzur Expires - October 2009 [Page 5]
TDM over L2TPv3 April 2009

2.2 types

2.2. RTP Attribute-Value Pair AVP (AVP) (ICRQ, OCRQ, ICRP, OCRP)

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor Id (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type (AVP-TBA-2) (100) |D| PT |C| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Timestamp Clock Frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Presence of this AVP indicates that the RTP header is used in the TDM
pseudowire encapsulation. Use or non-use of the RTP header MUST
match for the two directions of a TDM PW. This AVP MAY be hidden
(the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to
0. The Length (before hiding) of this AVP is 16.

The D bit indicates the timestamping mode (absolute or differential)
in the RTP header. These modes are described in, e.g., in [RFC4553], Section 4.3.2. 4.3.2
of [RFC4553]. If the D bit is set to 1 1, then the Differential differential
timestamping mode is used, otherwise used; otherwise, the Absolute absolute timestamping mode
is used. Timestamping modes can be used independently for the two
directions of a TDM PW.

The C bit indicates the ordering of the RTP header and the control
word Control
Word as following:

o If the C bit is set to 1 1, the RTP header appears after the
control word Control
Word in the data channel of the TDM pseudowire. This mode is
described in [RFC4553] and [RFC5086] as SAToP/CESoPSN encapsulation
over IPv4/IPv6 PSN with L2TPv3 demultiplexing in [RFC4553] and
[RFC5086] demultiplexing, respectively.

o If the C bit is set to 0 0, the RTP header appears before the
control word. Control
Word. This mode is described as the old mode of the SAToP/CESoPSN
encapsulation over L2TPv3 in [RFC4553], Appendix
A, A of [RFC4553] and Appendix C
of [RFC5086], Annex C, respectively.

PT is the payload type expected in the RTP header. A value of zero 0
indicates that the receiver shall not check payload type to detect
malformed packets.

Timestamp Clock Frequency is the clock frequency used for the time
stamping
timestamping in units of 8 KHz.

SSRC indicates the expected value of SSRC the synchronization source
(SSRC) ID in the RTP header. A
zero 0 in this field means that the SSRC
ID will not be used for detecting

Vainshtein and Galtzur Expires - October 2009 [Page 6]
TDM over L2TPv3 April 2009 misconnections. Since L2TP
provides an alternative security mechanism using cookies, if the
cookie length is larger than zero 0, the SSRC SHOULD be zero.

2.3 0.

2.3. Changes in the Control Connection Management AVPs

Control Connections that support TDM PWs MUST add the appropriate PW
Type value(s) to the list in the Pseudowire Capabilities List AVP.
The valid values are listed in the next section.

2.4

2.4. Changes in the Session Connection Management AVPs

PW Type AVP should be set to one of the following values:

1. Structure-agnostic emulation [RFC4553] of:

a. E1 circuits - TBA-SAToP-E1 by IANA 0x0011

b. T1 (DS1) circuits - TBA-SAToP-T1 by IANA 0x0012

c. E3 circuits - TBA-SAToP-E3 by IANA 0x0013

d. T3 (DS3) circuits - TBA-SAToP-T3 by IANA 0x0014

2. Structure-aware emulation [RFC5086] of:

a. CESoPSN basic mode - TBA-CESoPSN-Basic by IANA 0x0015

b. Trunk-specific CESoPSN service with CAS - TBA-CESoPSN-
CAS by IANA 0x0017

TDM pseudowires use their own control word. Therefore Control Word. Therefore, the L2-
Specific Sublayer AVP MUST either be omitted or set to zero. 0.

TDM pseudowires use their own sequencing. Therefore Therefore, the Data
Sequencing AVP MUST either be omitted or set to zero. 0.

Note: The Control Word (CW) used in the SAToP and CESoPSN
encapsulations over L2TPv3 effectively represents a dedicated L2-
Specific Sub-layer. Sublayer.

3. Creation of the TDM Pseudowire Session

When LCCE an L2TP Control Connection Endpoint (LCCE) wants to open a
Session for a TDM PW PW, it MUST include the TDM PW AVP (in any case)
and the RTP AVP (if and only if the RTP header is used) in the ICRQ
or OCRQ (Outgoing-Call-Request) message. The LCCE peer must validate
the TDM PW AVP and make sure it can meet the requirements derived
from the RTP AVP (if it exists). If the peer agrees with the TDM AVP
AVP, it will send an appropriate ICRP or OCRP (Outgoing-Call-Reply)
message with the matching RTP AVP (if needed). The Initiator need initiator needs
to validate that it can supply the requirements derived from the
received RTP AVP.

Vainshtein and Galtzur Expires - October 2009 [Page 7]
TDM over L2TPv3 April 2009

The two peers MUST agree on the values in the TDM PW AVP:

1. Bit Rate values MUST be equal on both sides. If they are
different, the connection will be rejected with return code
RC-TBD-1 and error code EC-TBD-1. Result Code 30 and
Error Code 1.

2. In the case of trunk-specific CESoPSN with CAS, the trunk type (as
encoded in the CAS bits of the TDM AVP) MUST be the same for the
two sides. Otherwise Otherwise, the connection will be rejected with return code RC-TBD-1 and error code EC-TBD-2. Result
Code 30 and Error Code 2.

3. If one side does not support the payload bytes Payload Bytes value proposed by
the other one, the connection will be rejected with return
code RC-TBD-1 and error code EC-TBD-3. Result Code 30
and Error Code 3.

4. If one side cannot send the RTP header as requested by the other
side, the connection will be rejected with return code RC-
TBD-1 and error code EC-TBD-4. Result Code 30 and
Error Code 4.

5. If one side can send the RTP header but not with the requested
timestamp clock frequency, the connection will be rejected with return code RC-TBD-1 and error code EC-TBD-5.
Result Code 30 and Error Code 5.

If CE signaling for a CESoPSN basic PW is transported in a separate
PW instance, then the two PW instances:

1. MUST use the same PW type type.

2. MUST use the same values in all the fields of the TDM AVP
excluding the SP field field, which must be set to '01' for the TDM data
PW and to '10' for the PW carrying CE application
signaling signaling.

3. MUST both either use or not use the RTP header (and (and, accordingly,
include or not include the RTP AVP).

4. IANA Considerations

This draft requires assignment of

IANA assigned the following values by IANA: according to this document:

New L2TPv3 Pseudowire Types:

0x0011 (TBA-SAToP-E1) - Structure-agnostic E1 circuit
0x0012 (TBA-SAToP-T1) - Structure-agnostic T1 (DS1) circuit
0x0013 (TBA-SAToP-E3) - Structure-agnostic E3 circuit
0x0014 (TBA-SAToP-T3) - Structure-agnostic T3 (DS3) circuit
0x0015 (TBA-CESoPSN-Basic) - CESoPSN basic mode
0x0017 (TBA-CESoPSN-CAS) - CESoPSN TDM with CAS

Note that the values listed are suggested to match with the values defined in [RFC4446] for
the MPLS Pseudowire Types.

New attribute value pair Attribute-Value Pair IDs:

Vainshtein and Galtzur Expires - October 2009 [Page 8]
TDM over L2TPv3 April 2009

1. AVP-TBD-1

99 - TDM Pseudowire AVP
2. AVP-TBD-2
100 - RTP AVP

New return codes Result Codes for the CDN message:

1. RC-TBD-1

30 - return code Result Code to indicate connection was refused because of TDM
PW parameters. The error code Error Code indicates the problem.

New TDM PW Specific error codes, specific Error Codes, to be used with the RC-TDB-1 return code
For 30 Result Code for
the CDN message:

This is a new registry for IANA to maintain within the Result Code
AVP (Attribute Type 1) Values. Additional values may be assigned by
Expert Review [RFC5226].

0 - Reserved
1. EC-TBD-1 Reserved.
1 - Bit Rate values disagree.
2. EC-TBD-2
2 - Different trunk types in the case of trunk-
specific trunk-specific CESoPSN
with CAS
3. EC-TBD-3 CAS.
3 - Requested payload size too big or too small.
4. EC-TBD-4
4 - RTP header cannot be generated.
5. EC-TBD-5
5 - Requested timestamp clock frequency cannot be
generated generated.

5. Congestion Control

The congestion considerations from [RFC4553] and [RFC5086] apply
respectively to the structure-agnostic and CESoPSN modes of this
specification.

6. Security Considerations

This document specifies only the L2TPv3-based control plane for setup
of TDM PWs. Within this scope, there are no additional security
considerations on top of in addition to those discussed in [RFC3931].

Common data plane security considerations for the TDM PWs have been
discussed in some detail in both [RFC4553] and [RFC5086]. On top of
these, the L2TPv3-based data plane provides additional security
mechanisms based on the usage of cookies.

7. Acknowledgements

The authors want to thank Carlos Pignataro, Ignacio Goyret Goyret, and
Yaakov Stein for careful review and useful suggestions.

8. References

8.1. Normative references

Vainshtein and Galtzur Expires - October 2009 [Page 9]
TDM over L2TPv3 April 2009 References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997 1997.

[RFC3931] J. Lau, M. J., Ed., Townsley, M., Ed., and I. Goyret, Layer Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3), March 2005

[RFC5086] A. Vainshtein et al, Structure-aware TDM Circuit
Emulation Service over Packet Switched Network
(CESoPSN), (L2TPv3)", RFC 5086, December 2007
3931, March 2005.

[RFC4553] A. Vainshtein, Y. A., Ed., and YJ. Stein, Structure-Agnostic TDM Ed., "Structure-
Agnostic Time Division Multiplexing (TDM) over Packet (SAToP),
(SAToP)", RFC 4553, June 2006

Informative references

[RFC5087] Y. Stein et al, TDM 2006.

[RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and
P. Pate, "Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over IP, Packet Switched Network
(CESoPSN)", RFC 5087, 5086, December 2007.

8.2. Informative References

[RFC4446] L. Martini, M. Townsley, IANA L., "IANA Allocations for Pseudo
Wire Pseudowire Edge to Edge
Emulation (PWE3), (PWE3)", BCP 116, RFC 4446, April 2006

[RFC5287] A. Vainshtein, Y. 2006.

[RFC5087] Y(J). Stein, Control Protocol Extensions
for Setup of TDM Pseudowires in MPLS Networks, Shashoua, R., Insler, R., and M. Anavi, "Time
Division Multiplexing over IP (TDMoIP)", RFC 5287,
August 2008 5087,
December 2007.

[RFC5226] T. Narten, T. and H. Alvestrand, Guidelines "Guidelines for Writing an
IANA Considerations Section in RFCs, RFCs", BCP 26, RFC 5226,
May 2008 2008.

[RFC5287] Vainshtein, A. and Y(J). Stein, "Control Protocol
Extensions for the Setup of Time-Division Multiplexing
(TDM) Pseudowires in MPLS Networks", RFC 5287, August
2008.

Authors' Addresses

Sharon Galtzur
Rebellion Inc.
29 The Chilterns, Gloucester Green,
Oxford, OX1 2DF, UK
Email: sharon.galtzur@rebellion.co.uk

Alexander Vainshtein,
ECI Telecom,
30 ha-Sivim St. PO Box 500,
Petah-Tiqva 49517, Israel
Email:
EMail: Alexander.Vainshtein@ecitele.com

Vainshtein and

Sharon Galtzur Expires - October 2009 [Page 10]
Rebellion Inc.
29 The Chilterns, Gloucester Green,
Oxford, OX1 2DF, UK
EMail: sharon.galtzur@rebellion.co.uk