Internet DRAFT - draft-vainshtein-pwe3-tdm-control-protocol-extension
draft-vainshtein-pwe3-tdm-control-protocol-extension
Network Working Group A. Vainshtein (Axerra Networks)
Internet Draft
Expiration Date:
August 2005
February 2005
Control Protocol Extensions for Setup of TDM Pseudowires
draft-vainshtein-pwe3-tdm-control-protocol-extension-02.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be disclosed,
in accordance with RFC 3668.
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 a "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 pseudowires.
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).......................................3
3.3. Fragmentation Indicator (0x09)................................4
3.4. TDM Options (0x0B)............................................4
4. Extending CESoPSN Basic NxDS0 Services with CE Application
Signaling............................................................6
A. Vainshtein Standards Track [Page 1]
Control Protocol Extensions for Setup of TDM Pseudowires February 2005
5. LDP Status Codes..................................................7
6. IANA and Security Considerations..................................7
7. Acknowledgements..................................................7
8. REFERENCES........................................................7
8.1. MANDATORY REFERENCES..........................................7
8.2. INFORMATIONAL REFERENCES......................................8
1. Introduction
This document defines extension to the PWE3 control protocol [PWE3-
CONTROL] and PWE3 IANA allocations [PWE3-IANA] required for setup of
TDM pseudowires.
Structure-agnostic TDM pseudowires have been specified in [PWE3-SAToP]
and structure-aware ones in [PWE3-CESoPSN] and [PWE3-TDMoIP].
[PWE3-CONTROL] defines extensions of 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 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:
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). In this FEC:
a) PW ID is replaced by PW AGI, SAII and TAI
b) The control bit and the PW type remain the same as in the PWid
FEC
c) The interface parameters are moved to a separate Interface
Parameters TLV.
Both types of PW FEC can be used for setup of TDM PWs with appropriate
selection of PW types and interface parameters.
A.Vainshtein Expires August 2005 [Page 2]
Control Protocol Extensions for Setup of TDM Pseudowires February 2005
The PW Types for TDM PWs are allocated in [PWE3-IANA] like following:
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 basic mode [PWE3-TDMoIP]
o 0x0017 CESoPSN TDM with CAS [PWE3-CESoPSN]
o 0x0018 TDMoIP TDM with CAS [PWE3-TDMoIP]
The Control bit MUST always be set for setup of TDM PWs since all TDM
PW encapsulations use an appropriate control word.
3. Interface Parameters for TDM PWs
3.1. CEP/TDM Payload Bytes (0x04)
This parameter is used for setup of all types of TDM PWs 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,
default payload size defined for the corresponding service (see
[PWE3-SAToP], [PWE3-CESoPSN], [PWE3-TDMoIP] MUST be assumed
3. For structure-agnostic emulation, any value 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.
5. For TDMoIP PWs the value MUST be an integer multiple of 48.
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.Vainshtein Expires August 2005 [Page 3]
Control Protocol Extensions for Setup of TDM Pseudowires February 2005
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. 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.4. 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 following:
A.Vainshtein Expires August 2005 [Page 4]
Control Protocol Extensions for Setup of TDM Pseudowires February 2005
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 by
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 the timestamping clock in the 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,
A.Vainshtein Expires August 2005 [Page 5]
Control Protocol Extensions for Setup of TDM Pseudowires February 2005
Length can be set to 8 in this case.
Notes:
1. This interface parameter MAY be omitted in the following cases:
a) All the SAToP PWs that do not use RTP header [PWE3-SAToP]
b) Basic CESoPSN NxDS0 services without CE application signaling
[PWE3-CESoPSN]
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 below
c) CESoPSN PWs that carry trunk-specific NxDS0 services with CAS
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.
Using the TDM Options parameters for setup of TDMoIP PWs is left for
further study.
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.
A.Vainshtein Expires August 2005 [Page 6]
Control Protocol Extensions for Setup of TDM Pseudowires February 2005
If a 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
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.
In cases 2a, 2b and 2c above, the user will have to reconfigure the end
points to setup the PW.
In the case 2d the failure is fatal, and the only way to setup a PW
would be to use basic CESoPSN NxDS0 service with CE signaling packets.
6. IANA and Security Considerations
All the IANA assignments required by this draft are listed in [PWE3-
IANA].
This draft does not have any impact on security of PWs.
7. Acknowledgements
I thank Sharon Galtzur and Yaakov Stein for reviewing this text.
8. REFERENCES
8.1. MANDATORY 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
A.Vainshtein Expires August 2005 [Page 7]
Control Protocol Extensions for Setup of TDM Pseudowires February 2005
[PWE3-CONTROL] L. Martini et al, Pseudowire Setup and Maintenance using
LDP, Work in progress, December 2004, draft-ietf-pwe3-control-protocol-
14.txt
[PWE3-IANA] L. Martini, M. Townsley, IANA Allocations for pseudo Wire
Edge to Edge Emulation (PWE3), Work in progress, October 2004, draft-
ietf-pwe3-iana-allocation-07.txt
[PWE3-FRAG] A. Malis, M. Townsley, PWE3 Fragmentation and Reassembly,
Work in progress, February 2005, draft--ietf-pwe3-fragmentation-08.txt
[PWE3-SAToP] A. Vainshtein, Y. Stein, Structure-Agnostic TDM over
Packet (SAToP), Work in Progress, December 2003, draft-ietf-pwe3-SAToP-
01.txt
8.2. INFORMATIONAL REFERENCES
[PWE3-CESoPSN] A. Vainshtein et al, Structure-aware TDM Circuit
Emulation Service over Packet Switched Network (CESoPSN), Work in
progress, January 2005, draft-ietf-pwe3-cesopsn-02.txt
[PWE3-TDMoIP] Y. Stein et al, TDM over IP, Work in progress, draft-
ietf-pwe3-tdmoip-02.txt, July 2004.
Author's Address
Alexander ("Sasha") Vainshtein
Axerra Networks
24 Raoul Wallenberg St.,
Tel Aviv 69719, Israel
email: sasha@axerra.com
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. 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.
A.Vainshtein Expires August 2005 [Page 8]
