some type of compression, such as silence suppression or voice
compression.
The generic cell payload service will normally need sequence number
support and may also need real-time support. The generic cell
payload service would not normally require fragmentation.
The Encapsulation Layer may apply some form of compression to some of
these sub-types (e.g., idle cells may be suppressed).
In some instances, the cells to be incorporated in the payload may be
selected by filtering them from the stream of cells presented on the
wire. For example, an ATM PWE3 service may select cells based on
their VCI or VPI fields. This is a forwarder function, and the
selection would therefore be made before the packet was presented to
the PW Encapsulation Layer.
3.3.3. Bit Stream
A bit stream payload is created by capturing, transporting, and
replaying the bit pattern on the emulated wire, without taking
advantage of any structure that, on inspection, may be visible within
the relayed traffic (i.e., the internal structure has no effect on
the fragmentation into packets).
In some instances it is possible to apply suppression to bit streams.
For example, E1 and T1 send "all-ones" to indicate failure. This
condition can be detected without any knowledge of the structure of
the bit stream, and transmission of packetized can be data
suppressed.
This service will require sequencing and real-time support.
3.3.4. Structured Bit Stream
A structured bit stream payload is created by using some knowledge of
the underlying structure of the bit stream to capture, transport, and
replay the bit pattern on the emulated wire.
Two important points distinguish structured and unstructured bit
streams:
o Some parts of the original bit stream may be stripped in the
PSN-bound direction by an NSP block. For example, in
Structured SONET the section and line overhead (and possibly
more) may be stripped. A framer is required to enable such
stripping. It is also required for frame/payload alignment for
fractional T1/E1 applications.
o The PW must preserve the structure across the PSN so that the
CE-bound NSP block can insert it correctly into the
reconstructed unstructured bit stream. The stripped
information (such as SONET pointer justifications) may appear
in the encapsulation layer to facilitate this reconstitution.
As an option, the Encapsulation Layer may also perform silence/idle
suppression or similar compression on a structured bit stream.
Structured bit streams are distinguished from cells in that the
structures may be too long to be carried in a single packet. Note
that "short" structures are indistinguishable from cells and may
benefit from the use of methods described in section 3.3.2.
This service requires sequencing and real-time support.
3.3.5. Principle of Minimum Intervention
To minimize the scope of information, and to improve the efficiency
of data flow through the Encapsulation Layer, the payload should be
transported as received, with as few modifications as possible
[RFC1958].
This minimum intervention approach decouples payload development from
PW development and requires fewer translations at the NSP in a system
with similar CE interfaces at each end. It also prevents unwanted
side effects due to subtle misrepresentation of the payload in the
intermediate format.
An approach that does intervene can be more wire efficient in some
cases and may result in fewer translations at the NSP whereby the CE
interfaces are of different types. Any intermediate format
effectively becomes a new framing type, requiring documentation and
assured interoperability. This increases the amount of work for
handling the protocol that the intermediate format carries and is
undesirable.
4. Architecture of Pseudo Wires
This section describes the PWE3 architectural model.
4.1. Network Reference Model
Figure 2 illustrates the network reference model for point-to-point
PWs.
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudo Wire ------>| |
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
Native service Native service
Figure 2. PWE3 Network Reference Model
The two PEs (PE1 and PE2) have to provide one or more PWs on behalf
of their client CEs (CE1 and CE2) to enable the client CEs to
communicate over the PSN. A PSN tunnel is established to provide a
data path for the PW. The PW traffic is invisible to the core
network, and the core network is transparent to the CEs. Native data
units (bits, cells, or packets) arrive via the AC, are encapsulated
in a PW-PDU, and are carried across the underlying network via the
PSN tunnel. The PEs perform the necessary encapsulation and
decapsulation of PW-PDUs and handle any other functions required by
the PW service, such as sequencing or timing.
4.2. PWE3 Pre-processing
Some applications have to perform operations on the native data units
received from the CE (including both payload and signaling traffic)
before they are transmitted across the PW by the PE. Examples
include Ethernet bridging, SONET cross-connect, translation of
locally-significant identifiers such as VCI/VPI, or translation to
another service type. These operations could be carried out in
external equipment, and the processed data could be sent to the PE
over one or more physical interfaces. In most cases, could be in
undertaking these operations within the PE provides cost and
operational benefits. Processed data is then presented to the PW via
a virtual interface within the PE. These pre-processing operations
are included in the PWE3 reference model to provide a common
reference point, but the detailed description of these operations is
outside the scope of the PW definition given here.
PW
End Service
|
|<------- Pseudo Wire ------>|
| |
| |<-- PSN Tunnel -->| |
V V V V PW
+-----+----+ +----+ End Service
+-----+ |PREP | PE1|==================| PE2| | +-----+
| | | |............PW1.............|----------| |
| CE1 |----| | | | | | | CE2 |
| | ^ | |............PW2.............|----------| |
+-----+ | | | |==================| | | ^ +-----+
| +-----+----+ +----+ | |
| ^ | |
| | | |
| |<------- Emulated Service ------->| |
| | |
| Virtual physical |
| termination |
| ^ |
CE1 native | CE2 native
service | service
|
CE2 native
service
Figure 3. Pre-processing within the PWE3 Network Reference Model
Figure 3 shows the interworking of one PE with pre-processing (PREP),
and a second without this functionality. This reference point
emphasizes that the functional interface between PREP and the PW is
that represented by a physical interface carrying the service. This
effectively defines the necessary inter-working specification.
The operation of a system in which both PEs include PREP
functionality is also supported.
The required pre-processing can be divided into two components:
o Forwarder (FWRD)
o Native Service Processing (NSP)
4.2.1. Forwarders
Some applications have to forward payload elements selectively from
one or more ACs to one or more PWs. In such cases, there will also be
a need to perform the inverse function on PWE3-PDUs received by a PE
from the PSN. This is the function of the forwarder.
The forwarder selects the PW based on, for example, the incoming AC,
the contents of the payload, or some statically and/or dynamically
configured forwarding information.
+----------------------------------------+
| PE Device |
+----------------------------------------+
Single | | |
AC | | Single | PW Instance
<------>o Forwarder + PW Instance X<===========>
| | |
+----------------------------------------+
Figure 4a. Simple Point-to-Point Service
+----------------------------------------+
| PE Device |
+----------------------------------------+
Multiple| | Single | PW Instance
AC | + PW Instance X<===========>
<------>o | |
| |----------------------|
<------>o | Single | PW Instance
| Forwarder + PW Instance X<===========>
<------>o | |
| |----------------------|
<------>o | Single | PW Instance
| + PW Instance X<===========>
<------>o | |
+----------------------------------------+
Figure 4b. Multiple AC to Multiple PW Forwarding
Figure 4a shows a simple forwarder that performs some type of
filtering operation. Because the forwarder has a single input and a
single output interface, filtering is the only type of forwarding
operation that applies. Figure 4b shows a more general forwarding
situation where payloads are extracted from one or more ACs and
directed to one or more PWs. In this case filtering, direction, and
combination operations may be performed on the payloads. For
example, if the AC were Frame Relay, the forwarder might perform
Frame Relay switching and the PW instances might be the inter-switch
links.
4.2.2. Native Service Processing
Some applications required some form of data or address translation,
or some other operation requiring knowledge of the semantics of the
payload. This is the function of the Native Service Processor (NSP).
The use of the NSP approach simplifies the design of the PW by
restricting a PW to homogeneous operation. NSP is included in the
reference model to provide a defined interface to this functionality.
The specification of the various types of NSP is outside the scope of
PWE3.
+----------------------------------------+
| PE Device |
Multiple+----------------------------------------+
AC | | | Single | PW Instance
<------>o NSP # + PW Instance X<===========>
| | | |
|------| |----------------------|
| | | Single | PW Instance
<------>o NSP #Forwarder + PW Instance X<===========>
| | | |
|------| |----------------------|
| | | Single | PW Instance
<------>o NSP # + PW Instance X<===========>
| | | |
+----------------------------------------+
Figure 5. NSP in a Multiple AC to Multiple PW Forwarding PE
Figure 5 illustrates the relationship between NSP, forwarder, and PWs
in a PE. The NSP function may apply any transformation operation
(modification, injection, etc.) on the payloads as they pass between
the physical interface to the CE and the virtual interface to the
forwarder. These transformation operations will, of course, be
limited to those that have been implemented in the data path, and
that are enabled by the PE configuration. A PE device may contain
more than one forwarder.
This model also supports the operation of a system in which the NSP
functionality includes terminating the data-link, and the application
of Network Layer processing to the payload.
4.3. Maintenance Reference Model
Figure 6 illustrates the maintenance reference model for PWs.
|<------- CE (end-to-end) Signaling ------>|
| |<---- PW/PE Maintenance ----->| |
| | |<-- PSN Tunnel -->| | |
| | | Signaling | | |
| V V (out of scope) V V |
v +-----+ +-----+ v
+-----+ | PE1 |==================| PE2 | +-----+
| |-----|.............PW1..............|-----| |
| CE1 | | | | | | CE2 |
| |-----|.............PW2..............|-----| |
+-----+ | |==================| | +-----+
+-----+ +-----+
Customer Provider Provider Customer
Edge 1 Edge 1 Edge 2 Edge 2
Figure 6. PWE3 Maintenance Reference Model
The following signaling mechanisms are required:
o The CE (end-to-end) signaling is between the CEs. This
signaling could be Frame Relay PVC status signaling, ATM SVC
signaling, TDM CAS signaling, etc.
o The PW/PE Maintenance is used between the PEs (or NSPs) to set
up, maintain, and tear down PWs, including any required
coordination of parameters.
o The PSN Tunnel signaling controls the PW multiplexing and some
elements of the underlying PSN. Examples are L2TP control
protocol, MPLS LDP, and RSVP-TE. The definition of the
information that PWE3 needs signaled is within the scope of
PWE3, but the signaling protocol itself is not.
4.4. Protocol Stack Reference Model
Figure 7 illustrates the protocol stack reference model for PWs.
+-----------------+ +-----------------+
|Emulated Service | |Emulated Service |
|(e.g., TDM, ATM) |<==== Emulated Service ===>|(e.g., TDM, ATM) |
+-----------------+ +-----------------+
| Payload | | Payload |
| Encapsulation |<====== Pseudo Wire ======>| Encapsulation |
+-----------------+ +-----------------+
|PW Demultiplexer | |PW Demultiplexer |
| PSN Tunnel, |<======= PSN Tunnel ======>| PSN Tunnel, |
| PSN & Physical | | PSN & Physical |
| Layers | | Layers |
+-------+---------+ ___________ +---------+-------+
| / \ |
+===============/ PSN \===============+
\ /
\_____________/
Figure 7. PWE3 Protocol Stack Reference Model
The PW provides the CE with an emulated physical or virtual
connection to its peer at the far end. Native service PDUs from the
CE are passed through an Encapsulation Layer at the sending PE and
then sent over the PSN. The receiving PE removes the encapsulation
and restores the payload to its native format for transmission to the
destination CE.
4.5. Pre-processing Extension to Protocol Stack Reference Model
Figure 8 illustrates how the protocol stack reference model is
extended to include the provision of pre-processing (forwarding and
NSP). This shows the placement of the physical interface relative to