restrictions, which may not allow the preservation of the checksum.
For protocols such as ATM and FR, the scope of the checksum is
restricted to a single link. This is because the circuit identifiers
(e.g., FR DLCI or ATM VPI/VCI) only have local significance and are
changed on each hop or span. If the circuit identifier (and thus
checksum) were going to change as part of the PW emulation, it would
be more efficient to strip and recalculate the checksum.
The service-specific document for each protocol must describe the
validation scheme to be used.
6.5. Congestion Considerations
The PSN carrying the PW may be subject to congestion. The congestion
characteristics will vary with the PSN type, the network architecture
and configuration, and the loading of the PSN.
If the traffic carried over the PW is known to be TCP friendly (by,
for example, packet inspection), packet discard in the PSN will
trigger the necessary reduction in offered load, and no additional
congestion avoidance action is necessary.
If the PW is operating over a PSN that provides enhanced delivery,
the PEs should monitor packet loss to ensure that the requested
service is actually being delivered. If it is not, then the PE
should assume that the PSN is providing a best-effort service and
should use the best-effort service congestion avoidance measures
described below.
If best-effort service is being used and the traffic is not known to
be TCP friendly, the PEs should monitor packet loss to ensure that
the loss rate is within acceptable parameters. Packet loss is
considered acceptable if a TCP flow across the same network path and
experiencing the same network conditions would achieve an average
throughput, measured on a reasonable timescale, not less than that
which the PW flow is achieving. This condition can be satisfied by
implementing a rate-limiting measure in the NSP, or by shutting down
one or more PWs. The choice of which approach to use depends upon
the type of traffic being carried. Where congestion is avoided by
shutting down a PW, a suitable mechanism must be provided to prevent
it from immediately returning to service and causing a series of
congestion pulses.
The comparison to TCP cannot be specified exactly but is intended as
an "order-of-magnitude" comparison in timescale and throughput. The
timescale on which TCP throughput is measured is the round-trip time
of the connection. In essence, this requirement states that it is
not acceptable to deploy an application (using PWE3 or any other
transport protocol) on the best-effort Internet, which consumes
bandwidth arbitrarily and does not compete fairly with TCP within an
order of magnitude. One method of determining an acceptable PW
bandwidth is described in [RFC3448].
7. Control Plane
This section describes PWE3 control plane services.
7.1. Setup or Teardown of Pseudo Wires
A PW must be set up before an emulated service can be established and
must be torn down when an emulated service is no longer needed.
Setup or teardown of a PW can be triggered by an operator command,
from the management plane of a PE, by signaling set-up or teardown of
an AC (e.g., an ATM SVC), or by an auto-discovery mechanism.
During the setup process, the PEs have to exchange information (e.g.,
learn each other’s capabilities). The tunnel signaling protocol may
be extended to provide mechanisms that enable the PEs to exchange all
necessary information on behalf of the PW.
Manual configuration of PWs can be considered a special kind of
signaling and is allowed.
7.2. Status Monitoring
Some native services have mechanisms for status monitoring. For
example, ATM supports OAM for this purpose. For these services, the
corresponding emulated services must specify how to perform status
monitoring.
7.3. Notification of Pseudo Wire Status Changes
7.3.1. Pseudo Wire Up/Down Notification
If a native service requires bi-directional connectivity, the
corresponding emulated service can only be signaled as being up when
the PW and PSN tunnels (if used), are functional in both directions.
Because the two CEs of an emulated service are not adjacent, a
failure may occur at a place so that one or both physical links
between the CEs and PEs remain up. For example, in Figure 2, if the
physical link between CE1 and PE1 fails, the physical link between
CE2 and PE2 will not be affected and will remain up. Unless CE2 is
notified about the remote failure, it will continue to send traffic
over the emulated service to CE1. Such traffic will be discarded at
PE1. Some native services have failure notification so that when the
services fail, both CEs will be notified. For these native services,
the corresponding PWE3 service must provide a failure notification
mechanism.
Similarly, if a native service has notification mechanisms so that
all the affected services will change status from "Down" to "Up" when
a network failure is fixed, the corresponding emulated service must
provide a similar mechanism for doing so.
These mechanisms may already be built into the tunneling protocol.
For example, the L2TP control protocol [RFC2661] [RFC3931] has this
capability, and LDP has the ability to withdraw the corresponding
MPLS label.
7.3.2. Misconnection and Payload Type Mismatch
With PWE3, misconnection and payload type mismatch can occur.
Misconnection can breach the integrity of the system. Payload
mismatch can disrupt the customer network. In both instances, there
are security and operational concerns.
The services of the underlying tunneling mechanism and its associated
control protocol can be used to mitigate this. As part of the PW
setup, a PW-TYPE identifier is exchanged. This is then used by the
forwarder and the NSP to verify the compatibility of the ACs.
7.3.3. Packet Loss, Corruption, and Out-of-Order Delivery
A PW can incur packet loss, corruption, and out-of-order delivery on
the PSN path between the PEs. This can affect the working condition
of an emulated service. For some payload types, packet loss,
corruption, and out-of-order delivery can be mapped either to a bit
error burst, or to loss of carrier on the PW. If a native service
has some mechanism to deal with bit error, the corresponding PWE3
service should provide a similar mechanism.
7.3.4. Other Status Notification
A PWE3 approach may provide a mechanism for other status
notifications, if any are needed.
7.3.5. Collective Status Notification
The status of a group of emulated services may be affected
identically by a single network incident. For example, when the
physical link (or sub-network) between a CE and a PE fails, all the
emulated services that go through that link (or sub-network) will
fail. It is likely that a group of emulated services all terminate
at a remote CE. There may also be multiple such CEs affected by the
failure. Therefore, it is desirable that a single notification
message be used to notify failure of the whole group of emulated
services.
A PWE3 approach may provide a mechanism for notifying status changes
of a group of emulated circuits. One possible method is to associate
each emulated service with a group ID when the PW for that emulated
service is set up. Multiple emulated services can then be grouped by
associating them with the same group ID. In status notification,
this group ID can be used to refer all the emulated services in that
group. The group ID mechanism should be a mechanism provided by the
underlying tunnel signaling protocol.
7.4. Keep-Alive
If a native service has a keep-alive mechanism, the corresponding
emulated service must provide a mechanism to propagate it across the
PW. Transparently transporting keep-alive messages over the PW would
follow the principle of minimum intervention. However, to reproduce
the semantics of the native mechanism accurately, some PWs may
require an alternative approach, such as piggy-backing on the PW
signaling mechanism.
7.5. Handling Control Messages of the Native Services
Some native services use control messages for circuit maintenance.
These control messages may be in-band (e.g., Ethernet flow control,
ATM performance management, or TDM tone signaling) or out-of-band,
(e.g., the signaling VC of an ATM VP, or TDM CCS signaling).
Given the principle of minimum intervention, it is desirable that the
PEs participate as little as possible in the signaling and
maintenance of the native services. This principle should not,
however, override the need to emulate the native service
satisfactorily.
If control messages are passed through, it may be desirable to send
them by using either a higher priority or a reliable channel provided
by the PW Demultiplexer layer. See Section 5.1.2, PWE3 Channel
Types.
8. Management and Monitoring
This section describes the management and monitoring architecture for
PWE3.
8.1. Status and Statistics
The PE should report the status of the interface and tabulate
statistics that help monitor the state of the network and help
measure service-level agreements (SLAs). Typical counters include
the following:
o Counts of PW-PDUs sent and received, with and without errors.
o Counts of sequenced PW-PDUs lost.
o Counts of service PDUs sent and received over the PSN, with and
without errors (non-TDM).
o Service-specific interface counts.
o One-way delay and delay variation.
These counters would be contained in a PW-specific MIB, and they
should not replicate existing MIB counters.
8.2. PW SNMP MIB Architecture
This section describes the general architecture for SNMP MIBs used to
manage PW services and the underlying PSN. The intent here is to
provide a clear picture of how all the pertinent MIBs fit together to
form a cohesive management framework for deploying PWE3 services.
Note that the names of MIB modules used below are suggestions and do
not necessarily require that the actual modules used to realize the
components in the architecture be named exactly so.
8.2.1. MIB Layering
The SNMP MIBs created for PWE3 should fit the architecture shown in
Figure 12. The architecture provides a layered modular model into
which any supported emulated service can be connected to any
supported PSN type. This model fosters reuse of as much
functionality as possible. For instance, the emulated service layer
MIB modules do not redefine the existing emulated service MIB module;
rather, they only associate it with the pseudo wires used to carry
the emulated service over the configured PSN. In this way, the PWE3
MIB architecture follows the overall PWE3 architecture.
The architecture does allow for the joining of unsupported emulated
service or PSN types by simply defining additional MIB modules to
associate new types with existing ones. These new modules can
subsequently be standardized. Note that there is a separate MIB
module for each emulated service, as well as one for each underlying
PSN. These MIB modules may be used in various combinations as
needed.
Native
Service MIBs ... ... ...
| | |
+-----------+ +-----------+ +-----------+
Service | CEP | | Ethernet | | ATM |
Layer |Service MIB| |Service MIB| ... |Service MIB|
+-----------+ +-----------+ +-----------+
\ | /
\ | /
- - - - - - - - - - - - \ - - - | - - - - / - - - - - - -
\ | /
+-------------------------------------------+
Generic PW | Generic PW MIBs |
Layer +-------------------------------------------+
/ \
- - - - - - - - - - - - / - - - - - - - - \ - - - - - - -
/ \
/ \
+--------------+ +----------------+
PSN VC |L2TP VC MIB(s)| | MPLS VC MIB(s) |
Layer +--------------+ +----------------+
| |
Native +-----------+ +-----------+
PSN |L2TP MIB(s)| |MPLS MIB(s)|
MIBs +-----------+ +-----------+
Figure 12. MIB Module Layering Relationship
Figure 13 shows an example for a SONET PW carried over MPLS Traffic
Engineering Tunnel and an LDP-signaled LSP.
+-----------------+
| SONET MIB | RFC3592
+-----------------+
|
+------------------------------+
Service | Circuit Emulation Service MIB|
Layer +------------------------------+
- - - - - - - - - - - - - | - - - - - - - - - - - - -
+-----------------+
Generic PW | Generic PW MIB |
Layer +-----------------+
- - - - - - - - - - - - - | - - - - - - - - - - - - -
+-----------------+
PSN VC | MPLS VC MIBs |
Layer +-----------------+
| |
+-----------------+ +------------------+
| MPLS-TE-STD-MIB | | MPLS-LSR-STD-MIB |
+-----------------+ +------------------+
Figure 13. SONET PW over MPLS PSN Service-Specific Example
8.2.2. Service Layer MIB Modules
This conceptual layer in the model contains MIB modules used to
represent the relationship between emulated PWE3 services such as
Ethernet, ATM, or Frame Relay and the pseudo-wire used to carry that
service across the PSN. This layer contains corresponding MIB
modules used to mate or adapt those emulated services to the generic
pseudo-wire representation these are represented in the "Generic PW
MIB" functional block in Figure 13 above. This working group should
not produce any MIB modules for managing the general service; rather,
it should produce just those modules used to interface or adapt the
emulated service onto the PWE3 management framework as shown above.
For example, the standard SONET-MIB [RFC3592] is designed and
maintained by another working group. The SONET-MIB is designed to
manage the native service without PW emulation. However, the PWE3
working group is chartered to produce standards that show how to
emulate existing technologies such as SONET/SDH over pseudo-wires
rather than reinvent those modules.
8.2.3. Generic PW MIB Modules
The middle layer in the architecture is referred to as the Generic PW
Layer. MIBs in this layer are responsible for providing pseudo-wire
specific counters and service models used for monitoring and
configuration of PWE3 services over any supported PSN service. That
is, this layer provides a general model of PWE3 abstraction for
management purposes. This MIB is used to interconnect the MIB
modules residing in the Service Layer to the PSN VC Layer MIBs (see
section 8.2.4).
8.2.4. PSN VC Layer MIB Modules
The third layer in the PWE3 management architecture is referred to as
the PSN VC Layer. It is composed of MIBs that are specifically
designed to associate pseudo-wires onto those underlying PSN
transport technologies that carry the pseudo-wire payloads across the
PSN. In general, this means that the MIB module provides a mapping
between the emulated service that is mapped to the pseudo-wire via
the Service Layer and the Generic PW MIB Layer onto the native PSN
service. For example, in the case of MPLS, for example, it is
required that the general VC service be mapped into MPLS LSPs via the
MPLS-LSR-STD-MIB [RFC3813] or Traffic-Engineered (TE) Tunnels via the
MPLS-TE-STD-MIB [RFC3812]. In addition, the MPLS-LDP-STD-MIB
[RFC3815] may be used to reveal the MPLS labels that are distributed
over the MPLS PSN in order to maintain the PW service. As with the
native service MIB modules described earlier, the MIB modules used to
manage the native PSN services are produced by other working groups
that design and specify the native PSN services. These MIBs should
contain the appropriate mechanisms for monitoring and configuring the
PSN service that the emulated PWE3 service will function correctly.
8.3. Connection Verification and Traceroute
A connection verification mechanism should be supported by PWs.
Connection verification and other alarm mechanisms can 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 generic connection
verification or traceroute mechanism that passes 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 connection status
method.
For troubleshooting purposes, it is sometimes desirable to know the
exact functional path of a PW between PEs. This is provided by the
traceroute service of the underlying PSN. The opaque nature of the
PW means that this traceroute information is only available within
the provider network; e.g., at the PEs.
9. IANA Considerations
IANA considerations will be identified in the PWE3 documents that
define the PWE3 encapsulation, control, and management protocols.
10. Security Considerations
PWE3 provides no means of protecting the integrity, confidentiality,
or delivery of the native data units. The use of PWE3 can therefore
expose a particular environment to additional security threats.
Assumptions that might be appropriate when all communicating systems
are interconnected via a point-to-point or circuit-switched network
may no longer hold when they are interconnected with an emulated wire
carried over some types of PSN. It is outside the scope of this
specification to fully analyze and review the risks of PWE3,
particularly as these risks will depend on the PSN. An example
should make the concern clear. A number of IETF standards employ
relatively weak security mechanisms when communicating nodes are
expected to be connected to the same local area network. The Virtual
Router Redundancy Protocol [RFC3768] is one instance. The relatively
weak security mechanisms represent a greater vulnerability in an
emulated Ethernet connected via a PW.
Exploitation of vulnerabilities from within the PSN may be directed
to the PW Tunnel end point so that PW Demultiplexer and PSN tunnel
services are disrupted. Controlling PSN access to the PW Tunnel end
point is one way to protect against this. By restricting PW Tunnel
end point access to legitimate remote PE sources of traffic, the PE
may reject traffic that would interfere with the PW Demultiplexing
and PSN tunnel services.
Protection mechanisms must also address the spoofing of tunneled PW
data. The validation of traffic addressed to the PW Demultiplexer
end-point is paramount in ensuring integrity of PW encapsulation.
Security protocols such as IPSec [RFC2401] may be used by the PW
Demultiplexer Layer in order provide authentication and data
integrity of the data between the PW Demultiplexer End-points.
IPSec may provide authentication, integrity, and confidentiality, of
data transferred between two PEs. It cannot provide the equivalent
services to the native service.
Based on the type of data being transferred, the PW may indicate to
the PW Demultiplexer Layer that enhanced security services are
required. The PW Demultiplexer Layer may define multiple protection
profiles based on the requirements of the PW emulated service. CE-
to-CE signaling and control events emulated by the PW and some data
types may require additional protection mechanisms. Alternatively,
the PW Demultiplexer Layer may use peer authentication for every PSN
packet to prevent spoofed native data units from being sent to the
destination CE.
The unlimited transformation capability of the NSP may be perceived
as a security risk. In practice the type of operation that the NSP
may perform will be limited to those that have been implemented in
the data path. A PE designed and managed to best current practice
will have controls in place that protect and validate its
configuration, and these will be sufficient to ensure that the NSP
behaves as expected.
11. Acknowledgements
We thank Sasha Vainshtein for his work on Native Service Processing
and advice on bit stream over PW services and Thomas K. Johnson for
his work on the background and motivation for PWs.
We also thank Ron Bonica, Stephen Casner, Durai Chinnaiah, Jayakumar
Jayakumar, Ghassem Koleyni, Danny McPherson, Eric Rosen, John
Rutemiller, Scott Wainner, and David Zelig for their comments and
contributions.
12. References
12.1. Normative References
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two
Tunneling Protocol - Version 3 (L2TPv3), RFC 3931, March
2005.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC3592] Tesink, K., "Definitions of Managed Objects for the
Synchronous Optical Network/Synchronous Digital Hierarchy
(SONET/SDH) Interface Type", RFC 3592, September 2003.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.