band just like data messages through the corresponding PW to the
remote CE. In other words, no translation is needed at the PEs for
in-band maintenance messages. In addition, it MAY be desirable to
provide higher reliability for maintenance messages. The mechanisms
for providing high reliability do not have to be defined in the PWE3
WG.
Out-of-band maintenance messages between a CE and a PE may relate to
multiple ACs between the CE and the PE. They need to be processed at
the local PE and possibly at the remote PE as well. If a native
service has some out-of-band maintenance messages, the corresponding
emulated service MUST specify how to process such messages at the
PEs. In general, an out-of-band maintenance message is either
translated into an in-band maintenance message of the native service
or a PWE-specific maintenance message for every AC related to that
out-of-band message. As an example, assume the ACs between a CE and
a PE are some ATM VCCs inside a VPC. When a F4 AIS [UNI3.0] from the
CE is received by the PE, the PE should translate that F4 AIS into a
F5 AIS and send it to the remote CE for every VCC. Alternatively,
the PE should generate a PWE-specific maintenance message (e.g.,
label withdrawal) to the remote PE for every VCC. When the remote PE
receives such a PWE-specific maintenance message, it may need to
generate a maintenance message of the native service and send it to
the attached CE.
5.3. PE-initiated Maintenance Messages
A PE needs to initiate some maintenance messages under some
circumstances without being triggered by any native maintenance
messages from the CE. These circumstances are usually caused by
fault, e.g., a PW failure in the PSN or a link failure between the CE
and the PE.
The reason the PEs need to initiate some maintenance messages under a
fault condition is because the existence of a PW between two CEs
would otherwise reduce the CEs’ maintenance capability. This is
illustrated in the following example. If two CEs are directly
connected by a physical wire, a native service (e.g., ATM) can use
notifications from the lower layer (e.g., the physical link layer) to
assist its maintenance. For example, an ATM PVC can be signaled
"Down" if the physical wire fails. However, consider the following
scenario.
+-----+ Phy-link +----+ +----+ Phy-link +-----+
| CE1 |----------| PE1|......PW......|PE2 |----------| CE2 |
+-----+ +----+ +----+ +-----+
If the PW between PE1 and PE2 fails, CE1 and CE2 will not receive
physical link failure notification. As a result, they cannot declare
failure of the emulated circuit in a timely fashion, which will in
turn affect higher layer applications. Therefore, when the PW fails,
PE1 and PE2 need to initiate some maintenance messages to notify the
client layer on CE1 and CE2 that use the PW as a server layer. (In
this case, the client layer is the emulated service). Similarly, if
the physical link between PE1-CE1 fails, PE1 needs to initiate some
maintenance message(s) so that the client layer at CE2 will be
notified. PE2 may need to be involved in this process.
In the rare case when a physical wire between two CEs incurs many bit
errors, the physical link can be declared "Down" and the client layer
at the CEs be notified. Similarly, a PW can incur packet loss,
corruption, and out-of-order delivery. These can be considered as
"generalized bit error". Upon detection of excessive "generalized
bit error", a PW can be declared "Down" and the detecting PE needs to
initiate a maintenance message so that the client layer at the CE is
notified.
In general, every emulated service MUST specify:
* Under what circumstances PE-initiated maintenance messages are
needed,
* Format of the maintenance messages, and
* How to process the maintenance messages at the remote PE.
Some monitoring mechanisms are needed for detecting such
circumstances, e.g., a PW failure. Such mechanisms can be defined in
the PWE3 WG or elsewhere.
Status of a group of emulated circuits may be affected identically by
a single network incidence. For example, when the physical link
between a CE and a PE fails, all the emulated circuits that go
through that link will fail. It is desirable that a single
maintenance message be used to notify failure of the whole group of
emulated circuits connected to the same remote PE. A PWE3 approach
MAY provide some mechanism for notifying status changes of a group of
emulated circuits. One possible approach is to associate each
emulated circuit with a group ID while setting up the PW for that
emulated circuit. In a maintenance message, that group ID can be
used to refer to all the emulated circuits in that group.
If a PE needs to generate and send a maintenance message to a CE, the
PE MUST use a maintenance message of the native service. This is
essential in keeping the emulated service transparent to the CEs.
The requirements stated in this section are aligned with the ITU-T
maintenance philosophy for telecommunications networks [G805] (i.e.,
client layer/server layer concept).
6. Management of Emulated Services
Each PWE3 approach SHOULD provide some mechanisms for network
operators to manage the emulated service. These mechanisms can be in
the forms described below.
6.1. MIBs
SNMP MIBs [SMIV2] MUST be provided for managing each emulated circuit
as well as pseudo-wire in general. These MIBs SHOULD be created with
the following requirements.
6.2. General MIB Requirements
New MIBs MUST augment or extend where appropriate, existing tables as
defined in other existing service-specific MIBs for existing services
such as MPLS or L2TP. For example, the ifTable as defined in the
Interface MIB [IFMIB] MUST be augmented to provide counts of out-of-
order packets. A second example is the extension of the MPLS-TE-MIB
[TEMIB] when emulating circuit services over MPLS. Rather than
redefining the tunnelTable so that PWE can utilize MPLS tunnels, for
example, entries in this table MUST instead be extended to add
additional PWE-specific objects. A final example might be to extend
the IP Tunnel MIB [IPTUNMIB] in such a way as to provide PWE3-
specific semantics when tunnels other than MPLS are used as PSN
transport. Doing so facilitates a natural extension of those objects
defined in the existing MIBs in terms of management, as well as
leveraging existing agent implementations.
An AC MUST appear as an interface in the ifTable.
6.3. Configuration and Provisioning
MIB Tables MUST be designed to facilitate configuration and
provisioning of the AC.
The MIB(s) MUST facilitate intra-PSN configuration and monitoring of
ACs.
6.4. Performance Monitoring
MIBs MUST collect statistics for performance and fault management.
MIBs MUST provide a description of how existing counters are used for
PW emulation and SHOULD not replicate existing MIB counters.
6.5. Fault Management and Notifications
Notifications SHOULD be defined where appropriate to notify the
network operators of any interesting situations, including faults
detected in the AC.
Objects defined to augment existing protocol-specific notifications
in order to add PWE functionality MUST explain how these
notifications are to be emitted.
6.6. Pseudo-Wire Connection Verification and Traceroute
For network management purpose, a connection verification mechanism
SHOULD be supported by PWs. Connection verification as well as other
alarming mechanisms can alert network operators that a PW has lost
its remote connection. It is sometimes desirable to know the exact
functional path of a PW for troubleshooting purpose, thus a
traceroute function capable of reporting the path taken by data
packets over the PW SHOULD be provided.
7. Faithfulness of Emulated Services
An emulated service SHOULD be as similar to the native service as
possible, but NOT REQUIRED to be identical. The applicability
statement of a PWE3 service MUST report limitations of the emulated
service.
Some basic requirements on faithfulness of an emulated service are
described below.
7.1. Characteristics of an Emulated Service
From the perspective of a CE, an emulated circuit is characterized as
an unshared link or circuit of the chosen service, although service
quality of the emulated service may be different from that of a
native one. Specifically, the following requirements MUST be met:
1) It MUST be possible to define type (e.g., Ethernet, which is
inherited from the native service), speed (e.g., 100Mbps), and MTU
size for an emulated circuit, if it is possible to do so for a
native circuit.
2) If the two endpoints CE1 and CE2 of emulated circuit #1 are
connected to PE1 and PE2, respectively, and CE3 and CE4 of
emulated circuit #2 are also connected to PE1 and PE2, then the
PWs of these two emulated circuits may share the same physical
paths between PE1 and PE2. But from each CE’s perspective, its
emulated circuit MUST appear as unshared. For example, CE1/CE2
MUST NOT be aware of existence of emulated circuit #2 or CE3/CE4.
3) If an emulated circuit fails (either at one of the ACs or in the
middle of the PW), both CEs MUST be notified in a timely manner,
if they will be notified in the native service (see Section 5.3
for more information). The definition of "timeliness" is
service-dependent.
4) If a routing protocol (e.g., IGP) adjacency can be established
over a native circuit, it MUST be possible to be established over
an emulated circuit as well.
7.2. Service Quality of Emulated Services
It is NOT REQUIRED that an emulated service provide the same service
quality as the native service. The PWE3 WG only defines mechanisms
for providing PW emulation, not the services themselves. What
quality to provide for a specific emulated service is a matter
between a service provider (SP) and its customers, and is outside
scope of the PWE3 WG.
8. Non-Requirements
Some non-requirements are mentioned in various sections of this
document. Those work items are outside scope of the PWE3 WG. They
are summarized below:
- Service interworking;
In Service Interworking, the IWF (Interworking Function) between
two dissimilar protocols (e.g., ATM & MPLS, Frame Relay & ATM, ATM
& IP, ATM & L2TP, etc.) terminates the protocol used in one
network and translates (i.e., maps) its Protocol Control
Information (PCI) to the PCI of the protocol used in other network
for User, Control and Management Plane functions to the extent
possible.
- Selection of a particular type of PWs;
- To make the emulated services perfectly match their native
services;
- Defining mechanisms for signaling the PSN tunnels;
- Defining how to perform traffic management on packets that carry
PW PDUs;
- Providing any multicast service that is not native to the emulated
medium.
To illustrate this point, Ethernet transmission to a multicast
IEEE-48 address is considered in scope, while multicast services
like [MARS] that are implemented on top of the medium are out of
scope;
9. Quality of Service (QoS) Considerations
Some native services such as ATM can offer higher service quality
than best effort Internet service. QoS is therefore essential for
ensuring that emulated services are compatible (but not necessarily
identical) to their native forms. It is up to network operators to
decide how to provide QoS - They can choose to rely on over-
provisioning and/or deploy some QoS mechanisms.
In order to take advantage of QoS mechanisms defined in other working
groups, e.g., the traffic management schemes defined in DiffServ WG,
it is desirable that some mechanisms exists for differentiating the
packets resulted from PDU encapsulation. These mechanisms do not
have to be defined in the PWE3 approaches themselves. For example,
if the resulted packets are MPLS or IP packets, their EXP or DSCP
field can be used for marking and differentiating. A PWE3 approach
MAY provide guidelines for marking and differentiating.
The applicability of PWE3 to a particular service depends on the
sensitivity of that service (or the CE implementation) to
delay/jitter etc and the ability of the application layer to mask
them. PWE3 may not be applicable to services that have severe
constraints in this respect.
10. Inter-domain Issues
PWE is a matter between the PW end-points and is transparent to the
network devices between the PW end-points. Therefore, inter-domain
PWE is fundamentally similar to intra-domain PWE. As long as PW
end-points use the same PWE approach, they can communicate
effectively, regardless of whether they are in the same domain.
Security may become more important in the inter-domain case and some
security measure such as end-point authentication MAY be applied.
QoS may become more difficult to deliver too, as one service provider
has no control over another service provider’s provisioning and
traffic management policy. To solve the inter-domain QoS problem,
service providers have to cooperate. Once they agree at a
contractual level to provider high quality of service to certain
traffic (e.g., PWE traffic), the mechanisms defined in other working
groups, e.g., Diffserv WG, can be used.
Inter-domain PSN tunnels are generally more difficult to set up, tear
down and maintain than intra-domain ones. But that is an issue for
PSN tunneling protocols such as MPLS and L2TPv3 and is outside the
scope of PWE3.
11. Security Considerations
The PW end-point, PW demultiplexing mechanism, and the payloads of
the native service can all be vulnerable to attack. PWE3 should
leverage security mechanisms provided by the PW Demultiplexer or PSN
Layers. Such mechanisms SHOULD protect PW end-point and PW
Demultiplexer mechanism from denial-of-service (DoS) attacks and
spoofing of the native data units. Preventing unauthorized access to
PW end-points and other network devices is generally effective
against DoS attacks and spoofing, and can be part of protection
mechanism. Protection mechanisms SHOULD 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] can be
used.
12. Acknowledgments
The authors would like to acknowledge input from M. Aissaoui, M.
Bocci, S. Bryant, R. Cohen, N. Harrison, G. Heron, T. Johnson, A.
Malis, L. Martini, E. Rosen, J. Rutemiller, T. So, Y. Stein, and S.
Vainshtein.
13. References
13.1. Normative References
[IFMIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[SMIV2] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
13.2. Informative References
[G805] "Generic Functional Architecture of Transport Networks",
ITU-T Recommendation G.805, 2000.
[IPTUNMIB] Thaler, D., "IP Tunnel MIB", RFC 2667, August 1999.
[L2TPv3] Lau, J., Townsley, M., and I. Goyret, et al., "Layer Two
Tunneling Protocol (Version 3)", Work in Progress, June
2004.
[MARS] Armitage, G., "Support for Multicast over UNI 3.0/3.1
based ATM Networks", RFC 2022, November 1996.
[MPLS] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[PWE3_ARCH] S. Bryant and P. Pate, et. al., "PWE3 Architecture", Work
in Progress, March 2004.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[TEMIB] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) Management Information Base (MIB)", RFC 3812, June
2004.
[UNI3.0] ATM Forum, "ATM User-Network Interface Specification
Version 3.0", Sept. 1993.
14. Authors’ Addresses
XiPeng Xiao (Editor)
Riverstone Networks
5200 Great America Parkway
Santa Clara, CA 95054
EMail: xxiao@riverstonenet.com
Danny McPherson (Editor)
Arbor Networks
EMail: danny@arbor.net
Prayson Pate (Editor)
Overture Networks
507 Airport Boulevard, Suite 111
Morrisville, NC, USA 27560
EMail: prayson.pate@overturenetworks.com
Vijay Gill
AOL Time Warner
EMail: vijaygill9@aol.com
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
Thomas D. Nadeau
Cisco Systems, Inc.
300 Beaver Brook Drive
Boxborough, MA 01719
EMail: tnadeau@cisco.com
Craig White
Level 3 Communications, LLC.
1025 Eldorado Blvd.
Broomfield, CO, 80021
EMail: Craig.White@Level3.com
15. Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF’s procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.