Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, pwe3 mailing list <firstname.lastname@example.org>, pwe3 chair <email@example.com> Subject: Document Action: 'Structure-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN)' to Informational RFC The IESG has approved the following document: - 'Structure-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) ' <draft-ietf-pwe3-cesopsn-08.txt> as an Informational RFC This document is the product of the Pseudowire Emulation Edge to Edge Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cesopsn-08.txt
Technical Summary This draft extends the work described in RFC4553 by describing one method of encapsulating structured (NxDS0) Time Division Multiplexed (TDM) signals as pseudo-wires over packet-switching networks (PSN). The use of a structure aware method of emulating NxDS0 circuits provides for saving PSN bandwidth, supports DS0-level grooming and distributed cross-connect applications. It also enhances resilience of CE devices to effects of loss of packets in the PSN. The structured method described in this draft uses a structure locking mechanism in which there is a constant relationship between a particular DS0 circuit and the position in which the corresponding information is carried in the PW payload. The method provides the ability to keep the edge-to-edge delay of the emulated service independent of the service rate. Working Group Summary Although the Working Group was able to reach consensus on the unstructured TDM emulation method (SAToP/RFC4553), it could not reach consensus on the best method of emulating a structured service. The PWE3 WG therefore decided to pursue two methods as informational RFCs(draft-ietf-pwe3-cesopsn-07.txt and draft-ietf-pwe3-tdmoip-05.txt) and to gain operational experience with the technology before recommending a standards track approach. Protocol Quality There are many implementations of this protocol, and it is in operational service. Note to RFC Editor Section 4.4 OLD TEXT 4.4. Usage of the RTP header When a fixed RTP header (see [RFC3550], Section 5.1) is used with CESoPSN, its fields are used in the following way: NEW TEXT 4.4. Usage of the RTP header Although CESoPSN MAY employ an RTP header when explicit transfer of timing information is required, this is purely formal reuse of the header format. RTP mechanisms, such as header extensions, CSRC, list, padding, RTCP, RTP header compression, SRTP, etc. are not applicable to CESoPSN pseudowires. When a fixed RTP header (see [RFC3550], Section 5.1) is used with CESoPSN, its fields are used in the following way: END Section 9 (Security Considerations) OLD TEXT Although CESoPSN PWs MAY employ an RTP header when explicit transfer of timing information is required, SRTP (see [RFC3711]) mechanisms are NOT RECOMMENDED as a substitute for PW layer security. NEW TEXT Although CESoPSN MAY employ an RTP header when explicit transfer of timing information is required, it is not possible to use SRTP (see [RFC3711]) mechanisms as a substitute for PW layer security. OLD TEXT When using UDP as the multiplexing mechanism for PWs, manual configuration of both source and destination UDP ports MUST be used. In addition, CESoPSN assumes that UDP-based demultiplexing is aligned with traditional demultiplexing of peer-to-peer applications, i.e.: 1. Each CESoPSN IWF instance is associated with ("local association"): a) One of the routable IP addresses of its containing PE. This IP address is treated as the local end-point of the PSN tunnel b) A unique (within the scope defined by this address) UDP port number that is used as the local demultiplexor of the CESoPSN PW packets within the corresponding PSN tunnel 2. Each CESoPSN IWF instance is aware (e.g., by configuration) of the similar association of its remote peer ("remote association") and, in each packet it generates, uses: a) The IP address and the UDP port number of its "remote" association as correspondingly the Destination IP address and UDP port b) The IP address and the UDP port number of its "local" association as correspondingly the Source IP address and UDP port. NEW TEXT The destination UDP port MUST be used to multiplex and demultiplex individual PWs between nodes. Architecturally [RFC3985], this makes the destination UDP port act as the PW Label. UDP ports MUST be manually configured by both endpoints of the PW. The configured destination port together with both the source and destination IP addresses uniquely identifies the PW for the receiver. All UDP port values that function as PW labels SHOULD be in the range of dynamically allocated UDP port numbers (49152 through 65535). While many UDP-based protocols are able to traverse middleboxes without dire consequences, the use of UDP ports as PW labels makes middlebox traversal more difficult. Hence, it is NOT RECOMMENDED to use UDP-based PWs where port-translating middleboxes are present between PW endpoints.