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.