< draft-ietf-pwe3-arch-00.txt   draft-ietf-pwe3-arch-01.txt >
Pseudo-Wire Edge-to-Edge (PWE3) Working Group Stewart Bryant Pseudo-Wire Edge-to-Edge (PWE3) Working Group Stewart Bryant
Internet Draft Cisco Systems Internet Draft Cisco Systems
Document: <draft-ietf-pwe3-arch-00.txt> Document: <draft-ietf-pwe3-arch-01.txt>
Expires: April 2003 Prayson Pate Expires: May 2003 Prayson Pate
Overture Networks, Inc. Overture Networks, Inc.
Editors Editors
October 2002 November 2002
PWE3 Architecture PWE3 Architecture
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of section 10 of RFC2026. all provisions of section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 3, line 13 skipping to change at page 3, line 13
XiPeng Xiao Redback Networks XiPeng Xiao Redback Networks
Table of Contents Table of Contents
Status of this Memo.......................................... 1 Status of this Memo.......................................... 1
1. Introduction............................................. 5 1. Introduction............................................. 5
1.1 Pseudo Wire Definition............................... 5 1.1 Pseudo Wire Definition............................... 5
1.2 PW Service Functionality............................. 6 1.2 PW Service Functionality............................. 6
1.3 Non-Goals of this document........................... 6 1.3 Non-Goals of this document........................... 6
1.4 Terminology.......................................... 6
2. PWE3 Applicability....................................... 9 2. PWE3 Applicability....................................... 9
3. Protocol Layering Model.................................. 9 3. Protocol Layering Model.................................. 9
3.1 Protocol Layers...................................... 9 3.1 Protocol Layers...................................... 9
3.2 Domain of PWE3....................................... 10 3.2 Domain of PWE3....................................... 10
3.3 Payload Types........................................ 10 3.3 Payload Types........................................ 10
4. Architecture of Pseudo-wires............................. 14 4. Architecture of Pseudo-wires............................. 14
4.1 Network Reference Model.............................. 14 4.1 Network Reference Model.............................. 14
4.2 PWE3 Pre-processing.................................. 15 4.2 PWE3 Pre-processing.................................. 15
4.3 Maintenance Reference Model.......................... 19 4.3 Maintenance Reference Model.......................... 19
4.4 Protocol Stack Reference Model....................... 19 4.4 Protocol Stack Reference Model....................... 19
4.5 Pre-processing Extension to Protocol Stack Reference. 4.5 Pre-processing Extension to Protocol Stack...........
Model................................................ 20 Reference Model...................................... 20
5. PW Encapsulation......................................... 21 5. PW Encapsulation......................................... 21
5.1 Payload Convergence Layer............................ 22 5.1 Payload Convergence Layer............................ 22
5.2 Payload-independent PW Encapsulation Layers.......... 24 5.2 Payload-independent PW Encapsulation Layers.......... 24
5.3 Fragmentation........................................ 26 5.3 Fragmentation........................................ 27
5.4 Instantiation of the Protocol Layers................. 27 5.4 Instantiation of the Protocol Layers................. 27
6. PW Demultiplexer Layer and PSN Requirements.............. 30 6. PW Demultiplexer Layer and PSN Requirements.............. 30
6.1 Multiplexing......................................... 30 6.1 Multiplexing......................................... 30
6.2 Fragmentation........................................ 30 6.2 Fragmentation........................................ 30
6.3 Length and Delivery.................................. 30 6.3 Length and Delivery.................................. 30
6.4 PW-PDU Validation.................................... 30 6.4 PW-PDU Validation.................................... 31
6.5 Congestion Considerations............................ 31 6.5 Congestion Considerations............................ 31
7. Control Plane............................................ 31 7. Control Plane............................................ 31
7.1 Set-up or Teardown of Pseudo-Wires................... 31 7.1 Set-up or Teardown of Pseudo-Wires................... 31
7.2 Status Monitoring.................................... 32 7.2 Status Monitoring.................................... 32
7.3 Notification of Pseudo-wire Status Changes........... 32 7.3 Notification of Pseudo-wire Status Changes........... 32
7.4 Keep-alive........................................... 33 7.4 Keep-alive........................................... 34
7.5 Handling Control Messages of the Native Services..... 34 7.5 Handling Control Messages of the Native Services..... 34
8. Management and Monitoring................................. 34 8. Management and Monitoring................................. 34
8.1 Statistics........................................... 34 8.1 Statistics........................................... 34
8.2 PW SNMP MIB Architecture............................. 35 8.2 PW SNMP MIB Architecture............................. 35
8.3 Connection Verification and Traceroute................ 38 8.3 Connection Verification and Traceroute................ 38
9. IANA considerations...................................... 38 9. IANA considerations...................................... 38
10. Security Considerations................................. 38 10. Security Considerations................................. 38
skipping to change at page 6, line 34 skipping to change at page 6, line 34
o The detailed definition of the protocols involved in PW o The detailed definition of the protocols involved in PW
setup and maintenance. setup and maintenance.
The following are outside the scope of PWE3: The following are outside the scope of PWE3:
o Any multicast service not native to the emulated medium. o Any multicast service not native to the emulated medium.
Thus, Ethernet transmission to a "multicast" IEEE-48 address Thus, Ethernet transmission to a "multicast" IEEE-48 address
is in scope, while multicast services like MARS [RFC2022] that is in scope, while multicast services like MARS [RFC2022] that
are implemented on top of the medium are out of scope. are implemented on top of the medium are out of scope.
o Methods to signal or control the underlying PSN. o Methods to signal or control the underlying PSN.
1.4 Terminology 1.4 Terminology
Editor's note: Although it was decided at IETF-54 that the PWE3 Editor's note: Although it was decided at IETF-54 that the PWE3
common terminology should be published in a separate document, there common terminology should be published in a separate document, there
is case for it remaining in the architecture document. If the PWE3-WG is case for it remaining in the architecture document. If the PWE3-WG
confirms the desire to have a separate document, we will remove this confirms the desire to have a separate document, we will remove this
section in the next revision. section in the next revision.
This document uses the following definitions of terms. These terms This document uses the following definitions of terms. These terms
are illustrated in context in Figure 2. are illustrated in context in Figure 2.
skipping to change at page 7, line 32 skipping to change at page 7, line 32
Fragmentation The action of dividing a single PDU into Fragmentation The action of dividing a single PDU into
multiple PDUs before transmission with the multiple PDUs before transmission with the
intent of the original PDU being reassembled intent of the original PDU being reassembled
elsewhere in the network. Fragmentation may be elsewhere in the network. Fragmentation may be
performed in order to allow sending of packets performed in order to allow sending of packets
of a larger size than the network MTU which of a larger size than the network MTU which
they will traverse. they will traverse.
Maximum transmission The packet size (excluding data link header) Maximum transmission The packet size (excluding data link header)
unit (MTU) that an interface can be transmit without unit (MTU) that an interface can transmit without
needing to fragment. needing to fragment.
Native Service Processing of the data received by the PE Native Service Processing of the data received by the PE
Processing (NSP) from the CE before presentation to the PW Processing (NSP) from the CE before presentation to the PW
for transmission across the core. for transmission across the core.
Packet Switched Within the context of PWE3, this is a Packet Switched Within the context of PWE3, this is a
Network (PSN) network using IP or MPLS as the mechanism Network (PSN) network using IP or MPLS as the mechanism
for packet forwarding. for packet forwarding.
skipping to change at page 11, line 30 skipping to change at page 11, line 30
Typically a packet will be stripped of transmission overhead such as Typically a packet will be stripped of transmission overhead such as
HDLC flags and stuffing bits before transmission over the PW. HDLC flags and stuffing bits before transmission over the PW.
A packet payload would normally be relayed across the PW as a single A packet payload would normally be relayed across the PW as a single
unit. However, there will be cases where the combined size of the unit. However, there will be cases where the combined size of the
packet payload and its associated PWE3 and PSN headers exceeds the packet payload and its associated PWE3 and PSN headers exceeds the
PSN path MTU. In these cases, some fragmentation methodology needs PSN path MTU. In these cases, some fragmentation methodology needs
to be applied. This may, for example, be the case when a user is to be applied. This may, for example, be the case when a user is
providing the service and attaching to the service provider via an providing the service and attaching to the service provider via an
Ethernet, or where nested pseudo-wires are involved. Fragmentation is Ethernet, or where nested pseudo-wires are involved. Fragmentation is
discussed in more detail in Section 5. discussed in more detail in Section 5.3
A packet payload may need sequencing and real-time support. A packet payload may need sequencing and real-time support.
In some situations, the packet payload may be selected from the In some situations, the packet payload may be selected from the
packets presented on the emulated wire on the basis of some sub- packets presented on the emulated wire on the basis of some sub-
multiplexing technique. For example, one or more frame-relay PDUs multiplexing technique. For example, one or more frame-relay PDUs
may be selected for transport over a particular pseudo-wire based on may be selected for transport over a particular pseudo-wire based on
the frame-relay Data-Link Connection Identifier (DLCI), or, in the the frame-relay Data-Link Connection Identifier (DLCI), or, in the
case of Ethernet payloads, on the basis of the VLAN identifier. This case of Ethernet payloads, on the basis of the VLAN identifier. This
is an FWRD function, and this selection would therefore be made is an FWRD function, and this selection would therefore be made
before the packet was presented to the PW Encapsulation Layer. before the packet was presented to the PW Encapsulation Layer.
3.3.2. Cell Payload 3.3.2. Cell Payload
A cell payload is created by capturing, transporting and replaying A cell payload is created by capturing, transporting and replaying
groups of bits presented on the wire in a fixed-size format. The groups of bits presented on the wire in a fixed-size format. The
delineation of the group of bits that comprise the cell is specific delineation of the group of bits that comprise the cell is specific
to the encapsulation type. Two common examples of cell payloads are to the encapsulation type. Two common examples of cell payloads are
53-octet cells carrying ATM AAL2, and the larger 188-octet MPEG ATM 53-octet cells, and the larger 188-octet MPEG Transport Stream
Transport Stream packets [ETSI]. packets [ETSI].
To reduce per-PSN packet overhead, multiple cells may be concatenated To reduce per-PSN packet overhead, multiple cells may be concatenated
into a single payload. The Encapsulation Layer may consider the into a single payload. The Encapsulation Layer may consider the
payload complete on the expiry of a timer, or after a fixed number of payload complete on the expiry of a timer, after a fixed number of
cells have been received. The benefit of concatenating multiple PDUs cells have been received or when a significant cell (e.g. an ATM OAM
cell) has been received. The benefit of concatenating multiple PDUs
should be weighed against the resulting increase in jitter and the should be weighed against the resulting increase in jitter and the
larger penalty incurred by packet loss. In some cases, it may be larger penalty incurred by packet loss. In some cases, it may be
appropriate for the Encapsulation Layer to perform a silence appropriate for the Encapsulation Layer to perform a silence
suppression or a similar compression. suppression or a similar compression.
The generic cell payload service will normally need sequence number The generic cell payload service will normally need sequence number
support, and may also need real-time support. The generic cell support, and may also need real-time support. The generic cell
payload service would not normally require fragmentation. payload service would not normally require fragmentation.
The Encapsulation Layer may apply some form of compression to some of The Encapsulation Layer may apply some form of compression to some of
these sub-types. these sub-types (e.g. idle cells may be suppressed).
In some instances, the cells to be incorporated in the payload may be 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 selected by filtering them from the stream of cells presented on the
wire. For example, an ATM PWE3 service may select cells based on wire. For example, an ATM PWE3 service may select cells based on
their VCI or VPI fields. This is an NSP function, and the selection their VCI or VPI fields. This is an FWRD function, and the selection
would therefore be made before the packet was presented to the PW would therefore be made before the packet was presented to the PW
Encapsulation Layer. Encapsulation Layer.
3.3.3. Bit-stream 3.3.3. Bit-stream
A bit-stream payload is created by capturing, transporting and A bit-stream payload is created by capturing, transporting and
replaying the bit pattern on the emulated wire, without taking replaying the bit pattern on the emulated wire, without taking
advantage of any structure that, on inspection, may be visible within advantage of any structure that, on inspection, may be visible within
the relayed traffic (i.e. the internal structure has no effect on the the relayed traffic (i.e. the internal structure has no effect on the
fragmentation into packets). The Encapsulation Layer submits an fragmentation into packets).
identical number of bits for transport in each PW-PDU.
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 data suppressed.
This service will require sequencing and real-time support. This service will require sequencing and real-time support.
3.3.4. Structured bit-stream 3.3.4. Structured bit-stream
A bit-stream payload is created by using some knowledge of the A structured bit-stream payload is created by using some knowledge of
underlying structure of the bit-stream to capture, transport and the underlying structure of the bit-stream to capture, transport and
replay the bit pattern on the emulated wire (i.e. the internal replay the bit pattern on the emulated wire.
structure directly effects the fragmentation into packets).
Two important points distinguish structured and unstructured bit- Two important points distinguish structured and unstructured bit-
streams: streams:
o Some part of the original (unstructured) bit-stream are o Some part of the original bit-stream are stripped in
stripped by, for example, the PSN-bound direction of the the PSN-bound direction by NSP block. For example,
NSP block. For example, in Structured SONET the section in Structured SONET the section and line overhead (and,
and line overhead (and, possibly, more) may be stripped. possibly, more) may be stripped.
o The PW must preserve the structure across the PSN so that o The PW must preserve the structure across the PSN so that
the CE-bound NSP block can insert it correctly into the the CE-bound NSP block can insert it correctly into the
reconstructed unstructured bit-stream. reconstructed unstructured bit-stream.
The Encapsulation Layer may also perform silence/idle suppression or The Encapsulation Layer may also perform silence/idle suppression or
similar compression on a structured bit-stream. similar compression on a structured bit-stream.
Structured bit-streams are distinguished from cells in that the Structured bit-streams are distinguished from cells in that the
structures may be too long to be carried in a single packet (i.e. structures may be too long to be carried in a single packet. Note
structured SONET). Note that "short" structures are that "short" structures are indistinguishable from cells and may
indistinguishable from cells and may benefit from the use of cell benefit from the use of those PWE3 methods.
encapsulations.
This service will require sequencing and real-time support. This service will require sequencing and real-time support.
3.3.5. Principle of Minimum Intervention 3.3.5. Principle of Minimum Intervention
To minimise the scope of information, and to improve the efficiency To minimise the scope of information, and to improve the efficiency
of data flow through the Encapsulation Layer, the payload should be of data flow through the Encapsulation Layer, the payload should be
transported as received with as few modifications as possible transported as received with as few modifications as possible
[RFC1958]. [RFC1958].
This minimum intervention approach decouples payload development from This minimum intervention approach decouples payload development from
PW development and requires fewer translations at the NSP in a system PW development and requires fewer translations at the NSP in a system
with similar CE interfaces at each end. It also prevents any with similar CE interfaces at each end. It also prevents unwanted
unwanted side-effects due to subtle mis-representation of the payload side-effects due to subtle mis-representation of the payload in the
in the intermediate format. intermediate format.
An intervention approach can be more wire-efficient in some cases and An intervention approach can be more wire-efficient in some cases and
may result in fewer translations at the NSP where the CE interfaces may result in fewer translations at the NSP where the CE interfaces
are of different types. Any intermediate format effectively becomes a are of different types. Any intermediate format effectively becomes a
new framing type, requiring documentation and assured new framing type, requiring documentation and assured
interoperability. This increases the amount of work for handling the interoperability. This increases the amount of work for handling the
protocol the intermediate format carries, and is undesirable. protocol the intermediate format carries, and is undesirable.
4. Architecture of Pseudo-wires 4. Architecture of Pseudo-wires
skipping to change at page 14, line 44 skipping to change at page 14, line 44
Figure 2: PWE3 Network Reference Model Figure 2: PWE3 Network Reference Model
The two PEs (PE1 and PE2) need to provide one or more PWs on behalf The two PEs (PE1 and PE2) need to provide one or more PWs on behalf
of their client CEs (CE1 and CE2) to enable the client CEs to 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 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 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 network, and the core network is transparent to the CEs. Native data
units (bits, cells or packets) presented at the PW End Service (PWES) units (bits, cells or packets) presented at the PW End Service (PWES)
are encapsulated in a PW-PDU and carried across the underlying are encapsulated in a PW-PDU and carried across the underlying
network via the PSN tunnel. The PEs perform the necesssary network via the PSN tunnel. The PEs perform the necessary
encapsulation and decapsulation of PW-PDUs, as well as handling any encapsulation and decapsulation of PW-PDUs, as well as handling any
other functions required by the PW service, such as sequencing or other functions required by the PW service, such as sequencing or
timing. timing.
There are situations in which a particular packet payload needs to be There are situations in which a particular packet payload needs to be
multicast so that it is received by a number of CEs. This is useful multicast so that it is received by a number of CEs. This is useful
when using PWs as part of a "virtual LAN" service (see, e.g., when using PWs as part of a "virtual LAN" service (see, e.g.,
[VPLS]). This can be achieved by replicating the payload and [VPLS]). This can be achieved by replicating the payload and
transmitting the replicas on PWs, but it may also be useful to have a transmitting the replicas on PWs, but it may also be useful to have a
type of PW which is inherently point-to-multipoint. In that case, type of PW that is inherently point-to-multipoint. In that case, the
the PW would need to be carried through a point-to-multipoint PSN PW would need to be carried through a point-to-multipoint PSN tunnel,
tunnel, employing a multicast mechanism provided by the PSN. employing a multicast mechanism provided by the PSN.
4.2 PWE3 Pre-processing 4.2 PWE3 Pre-processing
In some applications, there is a need to perform operations on the In some applications, there is a need to perform operations on the
native data units received from the CE (including both payload and native data units received from the CE (including both payload and
signaling traffic) before they are transmitted across the PW by the signaling traffic) before they are transmitted across the PW by the
PE. Examples include Ethernet bridging, SONET cross-connect, PE. Examples include Ethernet bridging, SONET cross-connect,
translation of locally-significant identifiers such as VCI/VPI, or translation of locally-significant identifiers such as VCI/VPI, or
translation to another service type. These operations could be translation to another service type. These operations could be
carried out in external equipment, and the processed data sent to the carried out in external equipment, and the processed data sent to the
skipping to change at page 22, line 48 skipping to change at page 22, line 48
The Timing Layer and the Sequencing Layer provide generic services to The Timing Layer and the Sequencing Layer provide generic services to
the Payload Convergence Layer for all payload types, when required. the Payload Convergence Layer for all payload types, when required.
5.1 Payload Convergence Layer 5.1 Payload Convergence Layer
5.1.1. Encapsulation 5.1.1. Encapsulation
The primary task of the Payload Convergence Layer is the The primary task of the Payload Convergence Layer is the
encapsulation of the payload in PW-PDUs. The native data units to be encapsulation of the payload in PW-PDUs. The native data units to be
encapsulated may or may not contain L2 or L1 header information. encapsulated may or may not contain a L2 header or L1 overhead. This
This is service specific. The Payload Convergence header carries the is service specific. The Payload Convergence header carries the
additional information needed to replay the native data units at the additional information needed to replay the native data units at the
CE-bound physical interface. The PW Demultiplexer header is not CE-bound physical interface. The PW Demultiplexer header is not
considered as part of the PW header. considered as part of the PW header.
Not all the additional information needed to replay the native data Not all the additional information needed to replay the native data
units need to be carried in the PW header of the PW PDUs. Some units need 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 (e.g. service type of a PW) may be stored as state
information at the destination PE during PW set-up. information at the destination PE during PW set-up.
5.1.2. PWE3 Channel Types 5.1.2. PWE3 Channel Types
skipping to change at page 23, line 48 skipping to change at page 23, line 48
4. An un-sequenced channel for data traffic insensitive to packet 4. An un-sequenced channel for data traffic insensitive to packet
order. order.
The data channels (2, 3 and 4 above) should be carried "in band" with 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 one another to as much of a degree as is reasonably possible on a
PSN. PSN.
Where end-to-end connectivity may be disrupted by address translation Where end-to-end connectivity may be disrupted by address translation
[RFC3022], access-control lists, firewalls etc., there exists the [RFC3022], access-control lists, firewalls etc., there exists the
possibility that the control channel may be able to pass traffic and possibility that the control channel may be able to pass traffic and
set up the PW, but the PW data-path data traffic is blocked by one or set up the PW, but the PW data traffic is blocked by one or more of
more of these mechanisms. In these cases unless the control channel these mechanisms. In these cases unless the control channel is also
is also carried "in band" the signaling to set-up the PW will not carried "in band" the signaling to set-up the PW will not confirm
confirm the existence of an end-to-end data path. the existence of an end-to-end data path.
In some cases there is a need to synchronize some CE events with the In some cases there is a need to synchronize CE events with the data
data carried over a PW. This is especially the case with TDM carried over a PW. This is especially the case with TDM circuits
circuits (e.g., on-hook/off-hook events in PSTN switches). (e.g., the on-hook/off-hook events in PSTN switches might be carried
over a reliable control channel, whilst the associated bit-stream is
carried over a sequenced data channel).
PWE3 channel types that are not needed by the supported PWs need not PWE3 channel types that are not needed by the supported PWs need not
be included in such an implementation. be included in such an implementation.
5.1.3. Quality of Service Considerations 5.1.3. Quality of Service Considerations
Where possible, it is desirable to employ mechanisms to provide PW Where possible, it is desirable to employ mechanisms to provide PW
Quality of Service (QoS) support over PSNs. Quality of Service (QoS) support over PSNs.
5.2 Payload-independent PW Encapsulation Layers 5.2 Payload-independent PW Encapsulation Layers
skipping to change at page 24, line 46 skipping to change at page 24, line 48
protocol is not available, the existing protocol should be extended protocol is not available, the existing protocol should be extended
or modified to meet the PWE3 requirements, thereby making that or modified to meet the PWE3 requirements, thereby making that
protocol available for other IETF uses. In the particular case of protocol available for other IETF uses. In the particular case of
timing, more than one general method may be necessary to provide for timing, more than one general method may be necessary to provide for
the full scope of payload timing requirements. the full scope of payload timing requirements.
5.2.1. Sequencing 5.2.1. Sequencing
The sequencing function provides three services: frame ordering, The sequencing function provides three services: frame ordering,
frame duplication detection and frame loss detection. These services frame duplication detection and frame loss detection. These services
allow the invariant properties of a physical wire to be emulated. allow the emulation of the invariant properties of a physical wire.
Support for sequencing depends on the payload type, and may be Support for sequencing depends on the payload type, and may be
omitted if not needed. omitted if not needed.
The size of the sequence-number space depends on the speed of the The size of the sequence-number space depends on the speed of the
emulated service, and the maximum time of the transient conditions in emulated service, and the maximum time of the transient conditions in
the PSN. A sequence number space greater than approximately 2^16 may the PSN. A sequence number space greater than approximately 2^16 may
therefore be needed to prevent the sequence number space wrapping therefore be needed to prevent the sequence number space wrapping
during the transient. during the transient.
5.2.1.1 Frame Ordering 5.2.1.1 Frame Ordering
skipping to change at page 26, line 31 skipping to change at page 26, line 36
either timing information sent between the two PEs, or in some case either timing information sent between the two PEs, or in some case
timing information received from an external reference. timing information received from an external reference.
The Timing Sub-layer must therefore support two timing functions: The Timing Sub-layer must therefore support two timing functions:
clock recovery and timed payload delivery. A particular payload type clock recovery and timed payload delivery. A particular payload type
may require either or both of these services. may require either or both of these services.
5.2.2.1 Clock Recovery 5.2.2.1 Clock Recovery
Clock recovery is the extraction of output transmission bit timing Clock recovery is the extraction of output transmission bit timing
information from the delivered packet stream, and requires a phase- information from the delivered packet stream, and requires a suitable
locking mechanism. A physical wire provides this naturally, but it mechanism. A physical wire provides this naturally, but it is a
is a relatively complex task to extract this from a highly jittered relatively complex task to extract this from a highly jittered source
source such as packet stream. It is therefore desirable that an such as packet stream. It is therefore desirable that an existing
existing real-time protocol such as [RFC1889] be used for this real-time protocol such as [RFC1889] be used for this purpose, unless
purpose, unless it can be shown that this is unsuitable or it can be shown that this is unsuitable or unnecessary for a
unnecessary for a particular payload type. particular payload type.
5.2.2.2 Timed delivery 5.2.2.2 Timed delivery
Timed delivery is the delivery of non-contiguous PW PDUs to the PW Timed delivery is the delivery of non-contiguous PW PDUs to the PW
output interface with a constant phase relative to the input output interface with a constant phase relative to the input
interface. The timing of the delivery may be relative to a clock interface. The timing of the delivery may be relative to a clock
derived from the packet stream via clock recovery, or via an external derived from the packet stream received over the PSN clock recovery,
clock. or with reference to an external clock.
5.3 Fragmentation 5.3 Fragmentation
A payload would normally be relayed across the PW as a single unit. A payload would normally be relayed across the PW as a single unit.
However, there will be cases where the combined size of the payload However, there will be cases where the combined size of the payload
and its associated PWE3 and PSN headers exceeds the PSN path MTU. and its associated PWE3 and PSN headers exceeds the PSN path MTU.
When a packet exceeds the MTU of a given network, fragmentation and When a packet exceeds the MTU of a given network, fragmentation and
reassembly may have to be performed in order for the packet to be reassembly may have to be performed in order for the packet to be
delivered. Since fragmentation and reassembly generally consume a delivered. Since fragmentation and reassembly generally consume a
large amount of network resource as compared to simply switching a large amount of network resource as compared to simply switching a
packet in its entirety, efforts should be made to reduce or eliminate packet in its entirety, efforts should be made to reduce or eliminate
the need for fragmentation and reassembly as much as possible the need for fragmentation and reassembly as much as possible
throughout a network. Of particular concern for fragmentation and throughout a network. Of particular concern for fragmentation and
reassembly are aggregation points where large numbers of pseudowires reassembly are aggregation points where large numbers of pseudowires
are processed (e.g. at the PE). are processed (e.g. at the PE).
Ideally, the equipment originating the traffic being sent over the PW Ideally, the equipment originating the traffic being sent over the PW
will be configured to have adaptive measures (e.g. [RFC1191], will be configured to have adaptive measures (e.g. [RFC1191],
[RFC1981]) in place such that it never sends a packet which must be [RFC1981]) in place such that it never sends a packet that must be
fragmented. When this fails, the point closest to the sending host fragmented. When this fails, the point closest to the sending host
with fragmentation and reassembly capabilities should attempt to with fragmentation and reassembly capabilities should attempt to
reduce the size of packets further into the network. Thus, in the reduce the size of packets further into the network. Thus, in the
reference model for PWE3 [Figure 3] fragmentation should first be reference model for PWE3 [Figure 3] fragmentation should first be
performed at the CE if at all possible. If and only if the CE cannot performed at the CE if at all possible. If and only if the CE cannot
adhere to an acceptable MTU size for the PW should the PE attempt its adhere to an acceptable MTU size for the PW should the PE attempt its
own fragmentation method. own fragmentation method.
In cases where MTU management fails to limit the payload to a size 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 suitable for transmission of the PW, the PE may fall back to either a
skipping to change at page 29, line 5 skipping to change at page 29, line 11
As a special case, if the PW Demultiplexer is an MPLS label, the 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 section 5.4.2 can be used instead of the
protocol architecture of this section. protocol architecture of this section.
5.4.2. PWE3 over an MPLS PSN 5.4.2. PWE3 over an MPLS PSN
The MPLS ethos places importance on wire efficiency. By using a The MPLS ethos places importance on wire efficiency. By using a
control word, some components of the PWE3 protocol layers can be control word, some components of the PWE3 protocol layers can be
compressed to increase this efficiency. compressed to increase this efficiency.
+---------------------+ +---------------------+
| Payload | | Payload |
/=====================\ /=====================\
H Payload Convergence H-----------------+ H Payload Convergence H-----+
H---------------------H | H---------------------H |
H Timing H | H Timing H------------------------+
H---------------------H | H---------------------H | |
H Sequencing H-----------------| H Sequencing H-----| |
\=====================/ | \=====================/ | |
| PW Demultiplexer |---+ | | PW Demultiplexer |---+ | v
+---------------------+ | | +---------------------+ | | +--------------------------------+
| PSN Convergence |-----------------| | PSN Convergence |-----| . .
+---------------------+ | | +---------------------+ | | . RTP .
| PSN |-+ | v | PSN |-+ | | | |
+---------------------+ | | +--------------------------------+ +---------------------+ | | | +--------------------------------+
| MAC/Data-link | | | | Flags, Frag, Len, Seq #, etc | | MAC/Data-link | | | +->| Flags, Frag, Len, Seq #, etc |
+---------------------+ | | +--------------------------------+ +---------------------+ | | +--------------------------------+
| Physical | | +->| Inner Label | | Physical | | +--->| Inner Label |
+---------------------+ | +--------------------------------+ +---------------------+ | +--------------------------------+
+--->| Outer Label or MPLS-in-IP encap| +----->| Outer Label or MPLS-in-IP encap|
+--------------------------------+ +--------------------------------+
Figure 11: PWE3 over an MPLS PSN using a control word Figure 11: PWE3 over an MPLS PSN using a control word
Figure 11 shows the protocol layering for PWE3 over an MPLS PSN. An Figure 11 shows the protocol layering for PWE3 over an MPLS PSN. An
inner MPLS label is used to provide the PW demultiplexing function. 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 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 PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact
format. The flags in the control word provide the necessary payload format. The flags in the control word provide the necessary payload
convergence. A sequence field provides support for both in-order convergence. A sequence field provides support for both in-order
payload delivery and (supported by a fragmentation control method) a payload delivery and (supported by a fragmentation control method) a
PSN fragmentation service within the PSN Convergence Layer. Ethernet PSN fragmentation service within the PSN Convergence Layer. Ethernet
pads all frames to a minimum size of 64 bytes. The MPLS header does 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 not include a length indicator. Therefore to allow PWE3 to be carried
in MPLS to correctly pass over an Ethernet data-link, a length in MPLS to correctly pass over an Ethernet data-link, a length
correction field is needed in the control word. correction field is needed in the control word. As with an IP PSN,
where appropriate, timing is provided by RTP [RFC1889].
In some networks it may be necessary to carry PWE3 over MPLS over IP. 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 In these circumstances, the PW is encapsulated for carriage over MPLS
as described in this section, and then a standard method of carrying as described in this section, and then a method of carrying MPLS over
MPLS over an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the
the resultant PW-PDU. resultant PW-PDU.
6. PW Demultiplexer Layer and PSN Requirements 6. PW Demultiplexer Layer and PSN Requirements
PWE3 places three service requirements on the protocol layers used to PWE3 places three service requirements on the protocol layers used to
carry it across the PSN: carry it across the PSN:
o Multiplexing o Multiplexing
o Fragmentation o Fragmentation
o Length and Delivery o Length and Delivery
skipping to change at page 31, line 7 skipping to change at page 31, line 18
end-to-end integrity of frames. The PW service-specific mechanisms end-to-end integrity of frames. The PW service-specific mechanisms
MUST define whether the packet's checksum shall be preserved across MUST define whether the packet's checksum shall be preserved across
the PW or be removed from PE bound PDUs and then be re-calculated for the PW or be removed from PE bound PDUs and then be re-calculated for
insertion in CE bound data. insertion in CE bound data.
The former approach saves work, while the latter saves bandwidth. For The former approach saves work, while the latter saves bandwidth. For
a given implementation the choice may be dictated by hardware a given implementation the choice may be dictated by hardware
restrictions. restrictions.
For protocols such as ATM and FR, the scope of the checksum is For protocols such as ATM and FR, the scope of the checksum is
restriced to a single link. This is because the circuit identifiers restricted to a single link. This is because the circuit identifiers
(e.g. FR DLCI or ATM VPI/VCI) have only local significance and are (e.g. FR DLCI or ATM VPI/VCI) have only local significance and are
changed on each hop or span. If the circuit identifier (and thus changed on each hop or span. If the circuit identifier (and thus
checksum) were going to change as a part of the PW emulation, it checksum) were going to change as a part of the PW emulation, it
would be more efficient to strip and re-calculate the checksum. would be more efficient to strip and re-calculate the checksum.
The service specific document for each protocol must describe the The service specific document for each protocol must describe the
validation scheme to be used. validation scheme to be used.
6.5 Congestion Considerations 6.5 Congestion Considerations
skipping to change at page 34, line 37 skipping to change at page 34, line 46
PWE3. PWE3.
8.1 Statistics 8.1 Statistics
The PE can tabulate statistics that help monitor the state of the The PE can tabulate statistics that help monitor the state of the
network, and to help with measurement of service level agreements network, and to help with measurement of service level agreements
(SLAs). Typical counters include: (SLAs). Typical counters include:
o Counts of PW-PDUs sent and received, with and without errors. o Counts of PW-PDUs sent and received, with and without errors.
o Counts of sequenced PW-PDUs lost. o Counts of sequenced PW-PDUs lost.
o Counts of service PDUs sent and received, with and without o Counts of service PDUs sent and received over the PSN, with
errors (non-TDM). and without errors (non-TDM).
o Service-specific interface counts. o Service-specific interface counts.
These counters would be contained in a PW-specific MIB, and they These counters would be contained in a PW-specific MIB, and they
should not replicate existing MIB counters. should not replicate existing MIB counters.
8.2 PW SNMP MIB Architecture 8.2 PW SNMP MIB Architecture
This section describes the general architecture for SNMP MIBs used to This section describes the general architecture for SNMP MIBs used to
manage PW services and the underlying PSN. The intent here is to manage PW services and the underlying PSN. The intent here is to
provide a clear picture of how all of the pertinent MIBs fit together provide a clear picture of how all of the pertinent MIBs fit together
skipping to change at page 38, line 17 skipping to change at page 38, line 17
A connection verification mechanism should be supported by PWs. A connection verification mechanism should be supported by PWs.
Connection verification as well as other alarming mechanisms can Connection verification as well as other alarming mechanisms can
alert the operator that a PW has lost its remote connection. The alert the operator that a PW has lost its remote connection. The
opaque nature of a PW means that it is not possible to specify a opaque nature of a PW means that it is not possible to specify a
generic connection verification or traceroute mechanism that passes generic connection verification or traceroute mechanism that passes
this status to the CEs over the PW. If connection verification this status to the CEs over the PW. If connection verification
status of the PW is needed by the CE, it must be mapped to the native status of the PW is needed by the CE, it must be mapped to the native
connection status method. connection status method.
For troubleshooting purposes, it is sometimes desirable to know the For troubleshooting purposes, it is sometimes desirable to know the
exact functional path of a PW between PEs, thus a traceroute function exact functional path of a PW between PEs. This is provided by the
capable of reporting the path taken by data packets over the PW traceroute service of the underlying PSN. The opaque nature of the
should be provided. The opaque nature of the PW means that this PW means that this traceroute information is only available within
traceroute information is only available within the provider network the provider network e.g. at the PEs.
e.g. at the PEs.
9. IANA considerations 9. IANA considerations
There are no IANA considerations for this document. There are no IANA considerations for this document.
10. Security Considerations 10. Security Considerations
PWE3 provides no means of protecting the contents or delivery of the PWE3 provides no means of protecting the contents or delivery of the
native data units. PWE3 may, however, leverage security mechanisms native data units. PWE3 may, however, leverage security mechanisms
provided by the PW Demultiplexer or PSN Layers, such as IPSec provided by the PW Demultiplexer or PSN Layers, such as IPSec
skipping to change at page 40, line 10 skipping to change at page 40, line 11
Telecommunications Standards Institute (ETSI) Telecommunications Standards Institute (ETSI)
[LDP-MIB] Cucchiara, J., Sjostrand, H., and Luciani, J., [LDP-MIB] Cucchiara, J., Sjostrand, H., and Luciani, J.,
"Definitions of Managed Objects for the Multiprotocol "Definitions of Managed Objects for the Multiprotocol
Label Switching, Label Distribution Protocol (LDP)", Label Switching, Label Distribution Protocol (LDP)",
<draft-ietf-mpls-ldp-mib-08.txt>, work in progress, <draft-ietf-mpls-ldp-mib-08.txt>, work in progress,
August 2001. August 2001.
[LSRMIB] Srinivasan et al, "MPLS Label Switch Router Management [LSRMIB] Srinivasan et al, "MPLS Label Switch Router Management
Information Base Using SMIv2", Information Base Using SMIv2",
(draft-ietf-mpls-lsr-mib-08.txt, work in progress, January (draft-ietf-mpls-lsr-mib-08.txt, work in progress,
2002. January 2002.
[L2TPv3] Layer Two Tunneling Protocol (Version 3)'L2TPv3', J Lau, [L2TPv3] Layer Two Tunneling Protocol (Version 3)'L2TPv3', J Lau,
et. al. (work in progress). et. al. (work in progress).
[PPPoL2TP] PPP Tunneling Using Layer Two Tunneling Protocol, [PPPoL2TP] PPP Tunneling Using Layer Two Tunneling Protocol,
J Lau et al. <draft-ietf-l2tpext-l2tp-ppp-01.txt>, J Lau et al. <draft-ietf-l2tpext-l2tp-ppp-01.txt>,
work in progress. work in progress.
[PWMIB] Zelig et al, "Pseudo Wire (PW) Management Information Base [PWMIB] Zelig et al, "Pseudo Wire (PW) Management Information
Using SMIv2", (draft-ietf-pwe3-pw-mib-00.txt), work in Base Using SMIv2", (draft-ietf-pwe3-pw-mib-00.txt),
progress, June 2002. work in progress, June 2002.
[PWTCMIB] Nadeau et al, "Definitions for Textual Conventions and [PWTCMIB] Nadeau et al, "Definitions for Textual Conventions and
OBJECT-IDENTITIES for Pseudo-Wires Management" OBJECT-IDENTITIES for Pseudo-Wires Management"
(draft-ietf-pwe3-pw-tc-mib-00.txt), work in progress, (draft-ietf-pwe3-pw-tc-mib-00.txt), work in progress,
June 2002. June 2002.
[PWMPLSMIB] Danenberg et al, "SONET/SDH Circuit Emulation Service Over [PWMPLSMIB] Danenberg et al, "SONET/SDH Circuit Emulation Service
MPLS (CEM) Management Information Base Using SMIv2", Over MPLS (CEM) Management Information Base Using
(draft-ietf-pwe3-cep-mib-00.txt), work in progress, SMIv2", (draft-ietf-pwe3-cep-mib-00.txt), work in
August 2001. progress, August 2001.
[RFC1191] RFC-1191: Path MTU discovery. J.C. Mogul, S.E. Deering. [RFC1191] RFC-1191: Path MTU discovery. J.C. Mogul, S.E. Deering.
[RFC1889] RFC-1889: RTP: A Transport Protocol for Real-Time [RFC1889] RFC-1889: RTP: A Transport Protocol for Real-Time
Applications. H. Schulzrinne et. al. Applications. H. Schulzrinne et. al.
[RFC1902] RFC-1902: Structure of Management Information for [RFC1902] RFC-1902: Structure of Management Information for
Version 2 of the Simple Network Management Protocol Version 2 of the Simple Network Management Protocol
(SNMPv2), Case et al, January 1996. (SNMPv2), Case et al, January 1996.
[RFC1958] RFC-1958: Architectural Principles of the Internet, [RFC1958] RFC-1958: Architectural Principles of the Internet,
B. Carpenter et al. B. Carpenter et al.
[RFC1981] RFC-1981: Path MTU Discovery for IP version 6. J. McCann, [RFC1981] RFC-1981: Path MTU Discovery for IP version 6. J. McCann,
S. Deering, J.Mogul. S. Deering, J.Mogul.
[RFC2022] RFC-2022: Support for Multicast over UNI 3.0/3.1 based [RFC2022] RFC-2022: Support for Multicast over UNI 3.0/3.1 based
ATM Networks, G. Armitage. ATM Networks, G. Armitage.
[RFC2401] RFC-2401: Security Architecture for the Internet Protocol. [RFC2401] RFC-2401: Security Architecture for the Internet
S. Kent, R. Atkinson. Protocol. S. Kent, R. Atkinson.
[RFC2474] RFC-2474: Definition of the Differentiated Services [RFC2474] RFC-2474: Definition of the Differentiated Services
Field (DS Field) in the IPv4 and IPv6 Headers, Field (DS Field) in the IPv4 and IPv6 Headers,
K. Nichols, et. al. K. Nichols, et. al.
[RFC2661] RFC-2661: Layer Two Tunneling Protocol "L2TP". [RFC2661] RFC-2661: Layer Two Tunneling Protocol "L2TP".
W. Townsley, et. al. W. Townsley, et. al.
[RFC2784] RFC-2784: Generic Routing Encapsulation (GRE). [RFC2784] RFC-2784: Generic Routing Encapsulation (GRE).
D. Farinacci et al. D. Farinacci et al.
 End of changes. 39 change blocks. 
103 lines changed or deleted 108 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/