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