the CE.
/======================================\
H Forwarder H<----Pre-processing
H----------------======================/
H Native Service H | |
H Processing H | |
\================/ | |
| | | Emulated |
| Service | | Service |
| Interface | | (TDM, ATM, |
| (TDM, ATM, | | Ethernet, |<== Emulated Service ==
| Ethernet, | | Frame Relay, |
| Frame Relay, | | etc.) |
| etc.) | +-----------------+
| | | Payload |
| | | Encapsulation |<=== Pseudo Wire ======
| | +-----------------+
| | |PW Demultiplexer |
| | | PSN Tunnel, |
| | | PSN & Physical |<=== PSN Tunnel =======
| | | Headers |
+----------------+ +-----------------+
| Physical | | Physical |
+-------+--------+ +-------+---------+
| |
| |
| |
| |
| |
| |
To CE <---+ +---> To PSN
Figure 8. Protocol Stack Reference Model with Pre-processing
5. PW Encapsulation
The PW Encapsulation Layer provides the necessary infrastructure to
adapt the specific payload type being transported over the PW to the
PW Demultiplexer Layer used to carry the PW over the PSN.
The PW Encapsulation Layer consists of three sub-layers:
o Payload Convergence
o Timing
o Sequencing
The PW Encapsulation sub-layering and its context with the protocol
stack are shown in Figure 9.
+---------------------------+
| Payload |
/===========================\ <------ Encapsulation
H Payload Convergence H Layer
H---------------------------H
H Timing H
H---------------------------H
H Sequencing H
\===========================/
| PW Demultiplexer |
+---------------------------+
| PSN Convergence |
+---------------------------+
| PSN |
+---------------------------+
| Data-Link |
+---------------------------+
| Physical |
+---------------------------+
Figure 9. PWE3 Encapsulation Layer in Context
The Payload Convergence sub-layer is highly tailored to the specific
payload type. However grouping a number of target payload types into
a generic class, and then providing a single convergence sub-layer
type common to the group, reduces the number of payload convergence
sub-layer types. This decreases implementation complexity. The
provision of per-packet signaling and other out-of-band information
(other than sequencing or timing) is undertaken by this layer.
The Timing and Sequencing Layers provide generic services to the
Payload Convergence Layer for all payload types that require them.
5.1. Payload Convergence Layer
5.1.1. Encapsulation
The primary task of the Payload Convergence Layer is the
encapsulation of the payload in PW-PDUs. The native data units to be
encapsulated may contain an L2 header or L1 overhead. This is
service specific. The Payload Convergence header carries the
additional information needed to replay the native data units at the
CE-bound physical interface. The PW Demultiplexer header is not
considered part of the PW header.
Not all the additional information needed to replay the native data
units have to be carried in the PW header of the PW PDUs. Some
information (e.g., service type of a PW) may be stored as state
information at the destination PE during PW set up.
5.1.2. PWE3 Channel Types
The PW Encapsulation Layer and its associated signaling require one
or more of the following types of channels from its underlying PW
Demultiplexer and PSN Layers (channel type 1 plus one or more of
channel types 2 through 4):
1. A reliable control channel for signaling line events, status
indications, and, in exceptional cases, CE-CE events that must be
translated and sent reliably between PEs. PWE3 may need this type
of control channel to provide faithful emulation of complex data-
link protocols.
2. A high-priority, unreliable, sequenced channel. A typical use is
for CE-to-CE signaling. "High priority" may simply be indicated
via the DSCP bits for IP or the EXP bits for MPLS, giving the
packet priority during transit. This channel type could also use
a bit in the tunnel header itself to indicate that packets
received at the PE should be processed with higher priority
[RFC2474].
3. A sequenced channel for data traffic that is sensitive to packet
reordering (one classification for use could be for any non-IP
traffic).
4. An unsequenced channel for data traffic insensitive to packet
order.
The data channels (2, 3, and 4 above) should be carried "in band"
with one another to as much of a degree as is reasonably possible on
a PSN.
Where end-to-end connectivity may be disrupted by address translation
[RFC3022], access-control lists, firewalls, etc., the control channel
may be able to pass traffic and setup the PW, while the PW data
traffic is blocked by one or more of these mechanisms. In these
cases unless the control channel is also carried "in band", the
signaling to set up the PW will not confirm the existence of an end-
to-end data path. In some cases there is a need to synchronize CE
events with the data carried over a PW. This is especially the case
with TDM circuits (e.g., the on-hook/off-hook events in PSTN switches
might be carried over a reliable control channel whereas the
associated bit stream is carried over a sequenced data channel).
PWE3 channel types that are not needed by the supported PWs need not
be included in such an implementation.
5.1.3. Quality of Service Considerations
Where possible, it is desirable to employ mechanisms to provide PW
Quality of Service (QoS) support over PSNs.
5.2. Payload-Independent PW Encapsulation Layers
Two PWE3 Encapsulation sub-layers provide common services to all
payload types: Sequencing and Timing. These services are optional
and are only used if a particular PW instance needs them. If the
service is not needed, the associated header may be omitted in order
to conserve processing and network resources.
Sometimes a specific payload type will require transport with or
without sequence and/or real-time support. For example, an invariant
of Frame Relay transport is the preservation of packet order. Some
Frame Relay applications expect delivery in order and may not cope
with reordering of the frames. However, where the Frame Relay
service is itself only being used to carry IP, it may be desirable to
relax this constraint to reduce per-packet processing cost.
The guiding principle is that, when possible, an existing IETF
protocol should be used to provide these services. When a suitable
protocol is not available, the existing protocol should be extended
or modified to meet the PWE3 requirements, thereby making that
protocol available for other IETF uses. In the particular case of
timing, more than one general method may be necessary to provide for
the full scope of payload timing requirements.
5.2.1. Sequencing
The sequencing function provides three services: frame ordering,
frame duplication detection, and frame loss detection. These
services allow the emulation of the invariant properties of a
physical wire. Support for sequencing depends on the payload type
and may be omitted if it is not needed.
The size of the sequence-number space depends on the speed of the
emulated service, and on the maximum time of the transient conditions
in the PSN. A sequence number space greater than 2^16 may therefore
be needed to prevent the sequence number space from wrapping during
the transient.
5.2.1.1. Frame Ordering
When packets carrying the PW-PDUs traverse a PSN, they may arrive out
of order at the destination PE. For some services, the frames
(control frames, data frames, or both) must be delivered in order.
For these services, some mechanism must be provided for ensuring in-
order delivery. Providing a sequence number in the sequence sub-
layer header for each packet is one possible approach.
Alternatively, it can be noted that sequencing is a subset of the
problem of delivering timed packets, and that a single combined
mechanism such as [RFC3550] may be employed.
There are two possible misordering strategies:
o Drop misordered PW PDUs.
o Try to sort PW PDUs into the correct order.
The choice of strategy will depend on
o how critical the loss of packets is to the operation of the PW
(e.g., the acceptable bit error rate),
o the speeds of the PW and PSN,
o the acceptable delay (as delay must be introduced to reorder),
and
o the expected incidence of misordering.
5.2.1.2. Frame Duplication Detection
In rare cases, packets traversing a PW may be duplicated by the
underlying PSN. For some services, frame duplication is not
acceptable. For these services, some mechanism must be provided to
ensure that duplicated frames will not be delivered to the
destination CE. The mechanism may be the same as that used to ensure
in-order frame delivery.
5.2.1.3. Frame Loss Detection
A destination PE can determine whether a frame has been lost by
tracking the sequence numbers of the PW PDUs received.
In some instances, if a PW PDU fails to arrive within a certain time,
a destination PE will have to presume that it is lost. If a PW-PDU
that has been processed as lost subsequently arrives, the destination
PE must discard it.
5.2.2. Timing
A number of native services have timing expectations based on the
characteristics of the networks they were designed to travel over.
The emulated service may have to duplicate these network
characteristics as closely as possible: e.g., in delivering native
traffic with bitrate, jitter, wander, and delay characteristics
similar to those received at the sending PE.
In such cases, the receiving PE has to play out the native traffic as
it was received at the sending PE. This relies on timing information
either sent between the two PEs, or in some cases received from an
external reference.
Therefore, Timing Sub-layer must support two timing functions: clock
recovery and timed payload delivery. A particular payload type may
require either or both of these services.
5.2.2.1. Clock Recovery
Clock recovery is the extraction of output transmission bit timing
information from the delivered packet stream, and it requires a
suitable mechanism. A physical wire carries the timing information
natively, but extracting timing from a highly jittered source, such
as packet stream, is a relatively complex task. Therefore, it is
desirable that an existing real-time protocol such as [RFC3550] be
used for this purpose, unless it can be shown that this is unsuitable
or unnecessary for a particular payload type.
5.2.2.2. Timed Delivery
Timed delivery is the delivery of non-contiguous PW PDUs to the PW
output interface with a constant phase relative to the input
interface. The timing of the delivery may be relative to a clock
derived from the packet stream received over the PSN clock recovery,
or to an external clock.
5.3. Fragmentation
Ideally, a payload would be relayed across the PW as a single unit.
However, there will be cases where the combined size of the payload
and its associated PWE3 and PSN headers will exceed the PSN path MTU.
When a packet size exceeds the MTU of a given network, fragmentation
and reassembly have to be performed for the packet to be delivered.
Since fragmentation and reassembly generally consume considerable
network resources, as compared to simply switching a packet in its
entirety, the need for fragmentation and reassembly throughout a
network should be reduced or eliminated to the extent possible. Of
particular concern for fragmentation and reassembly are aggregation
points where large numbers of PWs are processed (e.g., at the PE).
Ideally, the equipment originating the traffic sent over the PW will
have adaptive measures in place (e.g., [RFC1191], [RFC1981]) that
ensure that packets needing to be fragmented are not sent. When this
fails, the point closest to the sending host with fragmentation and
reassembly capabilities should attempt to reduce the size of packets
to satisfy the PSN MTU. Thus, in the reference model for PWE3
(Figure 3), fragmentation should first be performed at the CE if
possible. Only if the CE cannot adhere to an acceptable MTU size for
the PW should the PE attempt its own fragmentation method.
In cases where MTU management fails to limit the payload to a size
suitable for transmission of the PW, the PE may fall back to either a
generic PW fragmentation method or, if available, the fragmentation
service of the underlying PSN.
It is acceptable for a PE implementation not to support
fragmentation. A PE that does not will drop packets that exceed the
PSN MTU, and the management plane of the encapsulating PE may be
notified.
If the length of a L2/L1 frame, restored from a PW PDU, exceeds the
MTU of the destination AC, it must be dropped. In this case, the
management plane of the destination PE may be notified.
5.4. Instantiation of the Protocol Layers
This document does not address the detailed mapping of the Protocol
Layering model to existing or future IETF standards. The
instantiation of the logical Protocol Layering model is shown in
Figure 9.
5.4.1. PWE3 over an IP PSN
The protocol definition of PWE3 over an IP PSN should employ existing
IETF protocols where possible.
+---------------------+ +-------------------------+
| Payload |------------->| Raw payload if possible |
/=====================\ +-------------------------+
H Payload Convergence H-----------+->| Flags, seq #, etc. |
H---------------------H / +-------------------------+
H Timing H---------/--->| RTP |
H---------------------H / +-------------+ |
H Sequencing H----one of | |
\=====================/ \ | +-----------+
| PW Demultiplexer |---------+--->| L2TP, MPLS, etc. |
+---------------------+ +-------------------------+
| PSN Convergence |------------->| Not needed |
+---------------------+ +-------------------------+
| PSN |------------->| IP |
+---------------------+ +-------------------------+
| Data-Link |------------->| Data-link |
+---------------------+ +-------------------------+
| Physical |------------->| Physical |
+---------------------+ +-------------------------+
Figure 10. PWE3 over an IP PSN
Figure 10 shows the protocol layering for PWE3 over an IP PSN. As a
rule, the payload should be carried as received from the NSP, with
the Payload Convergence Layer provided when needed. However, in
certain circumstances it may be justifiable to transmit the payload
in some processed form. The reasons for this must be documented in
the Encapsulation Layer definition for that payload type.
Where appropriate, explicit timing is provided by RTP [RFC3550],
which, when used, also provides a sequencing service. When the PSN
is UDP/IP, the RTP header follows the UDP header and precedes the PW
control field. For all other cases the RTP header follows the PW
control header.
The encapsulation layer may additionally carry a sequence number.
Sequencing is to be provided either by RTP or by the PW encapsulation
layer, but not by both.
PW Demultiplexing is provided by the PW label, which may take the
form specified in a number of IETF protocols; e.g., an MPLS label
[MPLSIP], an L2TP session ID [RFC3931], or a UDP port number
[RFC768]. When PWs are carried over IP, the PSN Convergence Layer
will not be needed.
As a special case, if the PW Demultiplexer is an MPLS label, the
protocol architecture of section 5.4.2 can be used instead of the
protocol architecture of this section.
5.4.2. PWE3 over an MPLS PSN
The MPLS ethos places importance on wire efficiency. By using a
control word, some components of the PWE3 protocol layers can be
compressed to increase this efficiency.
+---------------------+
| Payload |
/=====================\
H Payload Convergence H--+
H---------------------H | +--------------------------------+
H Timing H--------->| RTP |
H---------------------H | +--------------------------------+
H Sequencing H--+------>| Flags, Frag, Len, Seq #, etc |
\=====================/ | +--------------------------------+
| PW Demultiplexer |--------->| PW Label |
+---------------------+ | +--------------------------------+
| PSN Convergence |--+ +--->| Outer Label or MPLS-in-IP encap|
+---------------------+ | +--------------------------------+
| PSN |-----+
+---------------------+
| Data-Link |
+---------------------+
| Physical |
+---------------------+
Figure 11. PWE3 over an MPLS PSN Using a Control Word
Figure 11 shows the protocol layering for PWE3 over an MPLS PSN. An
inner MPLS label is used to provide the PW demultiplexing function.
A control word is used to carry most of the information needed by the
PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact
format. The flags in the control word provide the necessary payload
convergence. A sequence field provides support for both in-order
payload delivery and a PSN fragmentation service within the PSN
Convergence Layer (supported by a fragmentation control method).
Ethernet pads all frames to a minimum size of 64 bytes. The MPLS
header does not include a length indicator. Therefore, to allow PWE3
to be carried in MPLS to pass correctly over an Ethernet data-link, a
length correction field is needed in the control word. As with an IP
PSN, where appropriate, timing is provided by RTP [RFC3550].
In some networks, it may be necessary to carry PWE3 over MPLS over
IP. In these circumstances, the PW is encapsulated for carriage over
MPLS as described in this section, and then a method of carrying MPLS
over an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the
resultant PW-PDU.
5.4.3. PW-IP Packet Discrimination
For MPLS PSNs, there is an additional constraint on the PW packet
format. Some label switched routers detect IP packets based on the
initial four bits of the packet content. To facilitate proper
functioning, these bits in PW packets must not be the same as an IP
version number in current use.
6. PW Demultiplexer Layer and PSN Requirements
PWE3 places three service requirements on the protocol layers used to
carry it across the PSN:
o Multiplexing
o Fragmentation
o Length and Delivery
6.1. Multiplexing
The purpose of the PW Demultiplexer Layer is to allow multiple PWs to
be carried in a single tunnel. This minimizes complexity and
conserves resources.
Some types of native service are capable of grouping multiple
circuits into a "trunk"; e.g., multiple ATM VCs in a VP, multiple
Ethernet VLANs on a physical media, or multiple DS0 services within a
T1 or E1. A PW may interconnect two end-trunks. That trunk would
have a single multiplexing identifier.
When a MPLS label is used as a PW Demultiplexer, setting of the TTL
value [RFC3032] in the PW label is application specific.
6.2. Fragmentation
If the PSN provides a fragmentation and reassembly service of
adequate performance, it may be used to obtain an effective MTU that
is large enough to transport the PW PDUs. See section 5.3 for a full
discussion of the PW fragmentation issues.
6.3. Length and Delivery
PDU delivery to the egress PE is the function of the PSN Layer.
If the underlying PSN does not provide all the information necessary
to determine the length of a PW-PDU, the Encapsulation Layer must
provide it.
6.4. PW-PDU Validation
It is a common practice to use an error detection mechanism such as a
CRC or similar mechanism to ensure end-to-end integrity of frames.
The PW service-specific mechanisms must define whether the packet’s
checksum shall be preserved across the PW or be removed from PE-bound
PDUs and then be recalculated for insertion in CE-bound data.
The former approach saves work, whereas the latter saves bandwidth.
For a given implementation, the choice may be dictated by hardware