Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)
RFC 5086

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    pwe3 mailing list <pwe3@ietf.org>, 
    pwe3 chair <pwe3-chairs@tools.ietf.org>
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.