Internet Draft XiPeng Xiao
Document: draft-ietf-pwe3-requirements-04.txt Riverstone Networks
Expires: June 2003
Danny McPherson
TCB
Prayson Pate
Overture Networks
Editors
Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
draft-ietf-pwe3-requirements-04.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes base requirements for the Pseudo-Wire
Emulation Edge to Edge Working Group (PWE3 WG). It provides
guidelines for other working group documents that will define
mechanisms for providing pseudo-wire emulation of Ethernet, ATM,
Frame Relay, raw HDLC, and MPLS. Requirements for pseudo-wire
emulation of TDM (i.e. "synchronous bit streams at rates defined by
ITU G.702") are defined in another document. It should be noted that
the PWE3 WG standardizes mechanisms that can be used to provide PWE3
services, but not the services themselves.
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
Co-Authors
The following are co-authors of this document:
Vijay Gill AOL Time Warner, Inc.
Kireeti Kompella Juniper Networks, Inc.
Thomas D. Nadeau Cisco Systems
Craig White Level 3 Communications, LLC.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Expires 06/03 Xiao/McPherson/Pate [Page 2]
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
Table of Contents
1 Terminology .................................................. 4
2 Introduction ................................................. 4
2.1 What Are Pseudo Wires? ..................................... 4
2.2 Background and Motivation .................................. 5
2.3 Current Network Architecture ............................... 5
2.4 PWE3 as a Path to Convergence .............................. 6
2.5 Suitable Applications for PWE3 ............................. 6
2.6 Summary .................................................... 6
3 Reference Model of PWE3 ...................................... 7
4 Packet Processing ............................................ 8
4.1 Encapsulation .............................................. 8
4.2 Frame Ordering ............................................. 9
4.3 Frame Duplication .......................................... 9
4.4 Segmentation and Reassembly ................................ 9
4.5 Handling Control Messages of the Native Services ........... 9
4.6 Consideration of Per-PSN Packet Overhead ................... 10
5 Maintenance of Emulated Services ............................. 10
5.1 Setup and Teardown of Pseudo-Wires ......................... 10
5.2 Status Monitoring .......................................... 10
5.3 Notification of Status Changes ............................. 11
5.4 Keep-alive ................................................. 12
6 Management of Emulated Services .............................. 12
6.1 MIBs ....................................................... 12
6.2 General MIB Requirements ................................... 12
6.3 Configuration and Provisioning ............................. 13
6.4 Performance Monitoring ..................................... 13
6.5 Fault Management and Notifications ......................... 13
6.6 Pseudo-Wire Connection Verification and Traceroute ........ 13
7 Faithfulness of Emulated Services ............................ 13
7.1 Characteristics of an Emulated Service ..................... 14
7.2 Service Quality of Emulated Services ....................... 14
8 Non-Requirements ............................................. 14
9 Quality of Service (QoS) Considerations ...................... 15
10 Inter-domain Issues ......................................... 16
11 Security Considerations ..................................... 16
12 Acknowledgments ............................................. 16
13 References .................................................. 16
14 Authors' Addresses .......................................... 17
15 Full Copyright Section ...................................... 19
Expires 06/03 Xiao/McPherson/Pate [Page 3]
Expires 06/03 Xiao/McPherson/Pate [Page 3]
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Some terms used throughout this document are listed below.
Customer Edge A device where one end of a service originates
and/or terminates. The CE is not aware that it is
using an emulated service rather than a native
service.
Packet Switched Network
A network using IP or MPLS as the mechanism for
packet forwarding
Provider Edge A device that provides PWE3 to a CE.
Pseudo Wire A mechanism that carries the essential elements of
an emulated service from one PE to one or more
other PEs over a PSN.
Pseudo Wire Emulation Edge to Edge
A mechanism that emulates the essential attributes
of a service (such as a T1 leased line or Frame
Relay) over a PSN.
Pseudo Wire PDU A PDU sent on the PW that contains all of the data
and control information necessary to emulate the
desired service.
PSN Tunnel A tunnel across a PSN inside which one or more PWs
can be carried.
2. Introduction
2.1. What Are Pseudo Wires?
Pseudo Wire Emulation Edge-to-Edge (PWE3) is a mechanism that
emulates the essential attributes of a service over a Packet Switched
Network (PSN). The required functions of PWs include encapsulating
service-specific PDUs arriving at an ingress port, and carrying them
across a path or tunnel, managing their timing and order, and any
other operations required to emulate the behavior and characteristics
of the service as faithfully as possible.
Expires 06/03 Xiao/McPherson/Pate [Page 4]
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
From the customer perspective, the PW is perceived as an unshared
link or circuit of the chosen service. However, there may be
deficiencies that impede some applications from being carried on a
PW. These limitations should be fully described in the appropriate
service-specific documents and Applicability Statements.
2.2. Background and Motivation
The following sections give some background on where networks are
today and why they are changing. It also talks about the motivation
to provide converged networks while continuing to support existing
services. Finally it discusses how PWs can be a solution for this
dilemma.
2.3. Current Network Architecture
2.3.1. Multiple Networks
For any given service provider delivering multiple services, the
current infrastructure usually consists of parallel or "overlay"
networks. Each of these networks implements a specific service, such
as Frame Relay, Internet access, etc. This is expensive, both in
terms of capital expense and operational costs. Furthermore, the
presence of multiple networks complicates planning. Service providers
wind up asking themselves these questions:
- Which of my networks do I build out?
- How many fibers do I need for each network?
- How do I efficiently manage multiple networks?
A converged network helps service providers answer these questions in
a consistent and economical fashion.
2.3.2. Transition to a Packet-Optimized Converged Network
In order to maximize return on their assets and minimize their
operating costs, service providers often look to consolidate the
delivery of multiple service types onto a single networking
technology.
As packet traffic takes up a larger and larger portion of the
available network bandwidth, it becomes increasingly useful to
optimize public networks for the Internet Protocol. However, many
service providers are confronting several obstacles in engineering
packet-optimized networks. Although Internet traffic is the fastest
growing traffic segment, it does not generate the highest revenue per
bit. For example, Frame Relay traffic currently generates higher
revenue per bit than native IP services do. Private line TDM
services still generate even more revenue per bit than does Frame
Expires 06/03 Xiao/McPherson/Pate [Page 5]
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
Relay. In addition, there is a tremendous amount of legacy equipment
deployed within public networks that does not communicate using the
Internet Protocol. Service providers continue to utilize non-IP
equipment to deploy a variety of services, and see a need to
interconnect this legacy equipment over their IP-optimized core
networks.
2.4. PWE3 as a Path to Convergence
How do service providers realize the capital and operational benefits
of a new packet-based infrastructure, while leveraging the existing
equipment and also protecting the large revenue stream associated
with this equipment? How do they move from mature Frame Relay or ATM
networks, while still being able to provide these lucrative services?
One possibility is the emulation of circuits or services via PWs.
Circuit emulation over ATM and interworking of Frame Relay and ATM
have already been standardized. Emulation allows existing services to
be carried across the new infrastructure, and thus enables the
interworking of disparate networks.
Implemented correctly, PWE3 can provide a means for supporting
today's services over a new network.
2.5. Suitable Applications for PWE3
What makes an application suitable (or not) for PWE3 emulation? When
considering PWs as a means of providing an application, the following
questions must be considered:
- Is the application sufficiently deployed to warrant emulation?
- Is there interest on the part of service providers in providing an
emulation for the given application?
- Is there interest on the part of equipment manufacturers in
providing products for the emulation of a given application?
- Are the complexities and limitations of providing an emulation
worth the savings in capital and operational expenses?
If the answer to all four questions is "yes", then the application is
likely to be a good candidate for PWE3. Otherwise, there may not be
sufficient overlap between the customers, service providers,
equipment manufacturers and technology to warrant providing such an
emulation.
2.6. Summary
To maximize the return on their assets and minimize their operational
costs, many service providers are looking to consolidate the delivery
of multiple service offerings and traffic types onto a single IP-
optimized network.
Expires 06/03 Xiao/McPherson/Pate [Page 6]
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
In order to create this next-generation converged network, standard
methods must be developed to emulate existing telecommunications
formats such as Ethernet, Frame Relay, and ATM over IP-optimized core
networks. This document describes requirements for accomplishing
this goal.
3. Reference Model of PWE3
A pseudo-wire (PW) is a connection between two provider edge (PE)
devices which connects two pseudo-wire end-services (PWESs). In this
document, A PWES is either:
- an Ethernet link or a VLAN link between two ports, or
- an ATM VC or VP, or
- a Frame Relay VC, or
- a raw HDLC circuit, or
- an MPLS LSP
between a customer edge (CE) device and a PE (See Figure 1).
|<------- Pseudo Wire ------>|
| |
| |<-- PSN Tunnel -->| |
PW V V V V PW
End Service+----+ +----+ End Service
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ | | |==================| | | +-----+
^ +----+ +----+ | ^
| Provider Edge 1 Provider Edge 2 |
| |
|<-------------- Emulated Service ---------------->|
Customer Customer
Edge 1 Edge 2
Figure 1: PWE3 Reference Model
During the setup of a PW, the two PEs will be configured or will
automatically exchange information about the service to be emulated
so that later they know how to process packets coming from the other
end. After a PW is set up between two PEs, frames received by one PE
from a PWES are encapsulated and sent over the PW to the remote PE,
where native frames are re-constructed and forwarded to the other CE.
For a detailed PWE3 architecture overview, readers should refer to
the PWE3 architecture document [PWE3_ARCH].
Expires 06/03 Xiao/McPherson/Pate [Page 7]
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
This document does not assume that a particular type of PWs (e.g.
[L2TPv3] sessions or [MPLS] LSPs) is used. Instead, it describes
generic requirements that apply to all PWs, for all services
including Ethernet, ATM, Frame Relay, raw HDLC and MPLS.
4. Packet Processing
This section describes forwarding plane requirements for PWE3.
4.1. Encapsulation
Every PE MUST provide service interfaces for encapsulating PDUs from
the PWESs. It should be noted that the PDUs to be encapsulated may
or may not contain L2 header information. This is service specific.
Every PWE3 service MUST specify what the PDU is.
A PW header consists of all the header fields in a PW PDU that are
used by the PW egress to determine how to process the PDU. The PSN
tunnel header is not considered as part of the PW header.
Specific requirements on PDU encapsulation are listed below.
4.1.1. Conveyance of Necessary L2 Header Information
The egress of a PW needs some information, e.g. which native service
the PW PDUs belong to, and possibly some L2 header information, in
order to know how to process the PDUs received. A PWE3 encapsulation
approach MUST provide some mechanism for conveying such information
from the PW ingress to the egress. It should be noted that not all
such information must be carried in the PW header of the PW PDUs.
Some information (e.g. service type of a PW) can be stored as state
information at the egress during PW setup.
4.1.2. Support of Variable Length PDUs
A PWE3 approach MUST accommodate variable length PDUs, if variable
length PDUs are allowed by the native service. For example, a PWE3
approach for Frame Relay MUST accommodate variable length frames.
4.1.3. Support of Multiplexing and Demultiplexing
If a service in its native form is capable of grouping multiple
circuits into a "trunk", e.g. multiple ATM VCs in a VP or multiple
Ethernet VLANs in a port, some mechanism SHOULD be provided so that a
single PW can be used to connect two end-trunks. From encapsulation
perspective, sufficient information MUST be carried so that the
egress of the PW can demultiplex individual circuits from the PW.
Expires 06/03 Xiao/McPherson/Pate [Page 8]
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
4.2. Frame Ordering
When packets carrying the PW PDUs traverse a PW, they may arrive at
the egress out of order. For some services, the frames (either
control frames only or both control and data frames) must be
delivered in order. For such services, some mechanism MUST be
provided for ensuring in-order delivery. Providing a sequence number
in the PW header for each packet is one possible approach.
4.3. Frame Duplication
In rare cases, packets traversing a PW may be duplicated. For some
services, frame duplication is not allowed. For such services some
mechanism MUST be provided to ensure that duplicated frames will not
be delivered. The mechanism may or may not be the same as the
mechanism used to ensure in-order frame delivery.
4.4. Segmentation and Reassembly
It is desirable to avoid packet Segmentation and Reassembly (SAR).
One way to do thus is to ensure that the combined size of the payload
and its associated PWE3 and PSN headers do not exceed the PSN path
MTU.
If SAR cannot be completely avoided, at a PW ingress, if the length
of a packet resulted from encapsulation exceeds the PSN path MTU, the
PDU MAY be dropped. In this case, the management plane of the ingress
PE MAY be notified. Alternatively, a segmentation mechanism MAY be
defined and used. At a PW egress, if the length of a L2 frame that is
restored from a PW PDU exceeds the MTU of destination PWES, it MUST
be dropped. In this case, the management plane of the egress PE MAY
be notified.
4.5. Handling Control Messages of the Native Services
Some native services use control messages for maintaining the
circuits. These control messages may be in-band, e.g. Ethernet flow
control or ATM performance management, or out-of-band, e.g. the
signaling VC of an ATM VP.
It is desirable that the PEs participate as little as possible in the
signaling and maintenance of the native services. However, it is up
to each specific PWE3 approach to specify what the PEs MUST do in
this regard. For an emulated service, it is possible that some
control messages (e.g. OAM) are processed at the PEs while others
(e.g. keep-alive) are passed through transparently like data messages
to the remote CE. If control messages are passed through, it MAY be
desirable to provide higher reliability for them. The mechanisms for
providing the high reliability NEED NOT be defined in the PWE3 WG.
Expires 06/03 Xiao/McPherson/Pate [Page 9]
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
4.6. Consideration of Per-PSN Packet Overhead
For ATM emulation, if each packet carries one cell, the PSN tunnel
header overhead is relatively large. In order to reduce overhead,
multiple cells MAY be concatenated before a PSN tunnel header is
added. Each encapsulated cell still carries its own PW header so that
the egress of the PW knows how to process it. However, the benefit of
concatenating multiple cells for header efficiency should be weighed
against the resulting increase in delay, jitter and the larger
penalty incurred by packet loss. In some cases, it may be appropriate
to perform silence suppression or other compression.
5. Maintenance of Emulated Services
This section describes control plane requirements for PWE3.
5.1. Setup and 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 and teardown of a PW can be triggered by a CLI command from the
management plane of a PE, or by signaling (i.e. setup or teardown) of
a PWES, e.g., an ATM SVC, or by an auto-discovery mechanism.
Every PWE3 approach MUST define some setup mechanism for establishing
the PWs. During the setup process, the PEs need to exchange some
information (e.g. learn each other's capability). The setup
mechanism MUST enable the PEs to exchange all necessary information.
For example, both endpoints must agree on methods for encapsulating
PDUs and handling frame ordering. Which signaling protocol to use and
what information to exchange are service specific. Every PWE3
approach MUST specify them. Manual configuration of PWs can be
considered as a special kind of signaling and is allowed.
Sessions in a L2TPv3 tunnel or MPLS LSPs can be used as PWs.
Selection of a particular type of PWs is carrier-dependent and is
outside scope of the PWE3 WG.
5.2. Status Monitoring
Some native services have mechanisms for status monitoring. For
example, ATM supports OAM for this purpose. For such services, the
corresponding emulated services MUST specify how to perform status
monitoring. The mechanisms NEED NOT be defined in this WG. Some
status monitoring mechanisms defined in other WGs, e.g. [LSPPING],
may be leveraged.
Expires 06/03 Xiao/McPherson/Pate [Page 10]
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
5.3. Notification of Status Changes
5.3.1. Up/Down Notification
If a native service is bi-directional, the corresponding emulated
service can only be signaled up when the associated PWs and PSN
tunnels in both directions are functional.
Because the two CEs of an emulated service are not adjacent, a
failure may occur at a place such that one or both physical links
between the CEs and PEs remain up. For example in Figure 1, 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 such native services,
the corresponding PWE3 service MUST provide a failure notification
mechanism.
Similarly, if a native service has notification mechanism so that
when a network failure is fixed, all the affected services will
change status from "Down" to "Up", the corresponding emulated service
MUST provide a mechanism for doing so.
5.3.2. Misconnection and Payload Type Mismatch
With PWE3, misconnection and payload type mismatch can occur. A PWE3
approach MAY define some mechanism for detecting and handling
misconnection and payload type mismatch.
5.3.3. Packet Loss, Corruption, and Out-of-order Delivery
A PW can incur packet loss, corruption, and out-of-order delivery.
This can impact the working condition of an emulated service. For
some payload types, packet loss, corruption, and out-of-order
delivery can be mapped to either a bit error burst, or 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.
5.3.4. Other Status Notification
A PWE3 approach MAY provide mechanism for other status notification,
if any.
5.3.5. Collective Status Notification
Expires 06/03 Xiao/McPherson/Pate [Page 11]
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
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 likely that there exists a group
of emulated circuits which all terminate at a remote CE. (There can
be multiple such CEs). Therefore, it is desirable that a single
notification message be used to notify failure of the whole group of
emulated circuits. 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 when the PW for that emulated circuit is set up. Multiple emulated
circuits can then be grouped by associating them with identical group
ID. In status notification, that group ID can be used to refer to all
the emulated circuits in that group.
5.4. Keep-alive
If a native service has keep-alive mechanism, the corresponding
emulated service MUST have keep-alive support. This can possibly be
done by transparently transporting the native keep-alive messages
across the PW. Alternatively, the keep-alive mechanism of the PW
signaling protocol (e.g. L2TPv3), if it exists, can be utilized.
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 service
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 PWES can utilize MPLS tunnels, for
example, entries in this table MUST instead be extended to add
additional PWES-specific objects. 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.
Interfaces implementing a PWES MUST appear as an interface in the
Expires 06/03 Xiao/McPherson/Pate [Page 12]
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
ifTable.
6.3. Configuration and Provisioning
MIB Tables MUST be designed to facilitate configuration and
provisioning of the PWES.
The MIB(s) MUST facilitate intra-PSN configuration and monitoring of
PWES connections.
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 PWES.
Objects defined to augment existing protocol-specific notifications
in order to add PWES 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 it is NOT REQUIRED that they are 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.
Expires 06/03 Xiao/McPherson/Pate [Page 13]
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
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 services 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 PWESs 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. 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. In fact, different SPs can use the same PWE3 approach with
different QoS mechanisms to provide the same emulated service with
different service quality.
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:
Expires 06/03 Xiao/McPherson/Pate [Page 14]
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
- 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;
- Striving 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 security for the 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
In this document, QoS means satisfactory service quality. It should
not be confused with QoS mechanisms such as Weighted Fair Queuing
(WFQ) or Random Early Detection (RED).
QoS is essential for ensuring that emulated services are similar (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 NEED NOT be
defined in the PWE3 approaches themselves. For example, if the
packets are MPLS or IP packets, their EXP or DSCP fields can be used
for marking and differentiating. A PWE3 approach MAY provide
Expires 06/03 Xiao/McPherson/Pate [Page 15]
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
guidelines for marking and differentiating, e.g. what fields in the
original L2 headers should be used for determining the EXP/DSCP
value. But the exact procedure of how to perform marking and
differentiating, e.g. specifying the mapping function from Ethernet
802.1p field to EXP field, is out of scope.
10. Inter-domain Issues
PWs are directly between the PW end-points. Whether a PSN tunnel is
inter-domain or not is transparent to PWE3. Therefore, inter-domain
issues caused by two PW end-points locating in different
administrative domains are issues for PSN-tunnel setup protocols such
as RSVP or LDP or L2TPv3, not for 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. Controlling PSN access to the PW
end-point 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 S. Bryant, R. Cohen,
G. Heron, T. Johnson, A. Malis, L. Martini, E. Rosen, J. Rutemiller,
T. So, Y. Stein and S. Vainshtein.
13. References
[IFMIB] K. McCloghrie, and F. Kastenholtz, "The Interfaces Group MIB
using SMIv2", RFC 2233, Nov. 1997.
[L2TPv3] J. Lau, M. Townsley, A. Valencia, G. Zorn, I. Goyret, G.
Pall, A. Rubens, B. Palter, "Layer Two Tunneling Protocol
(L2TPv3)", <draft-ietf-l2tpext-l2tp-base-04.txt>, work in
progress, Nov. 2002.
[LSPPING] K. Kompella, P. Pan, N. Sheth, D. Cooper, G. Swallow, S.
Wadhwa, and R. Bonica, "Detecting Data Plane Liveliness in
MPLS", <draft-ietf-mpls-lsp-ping-01.txt>, work in progress,
Oct. 2002.
Expires 06/03 Xiao/McPherson/Pate [Page 16]
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
[MARS] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based
ATM Networks", RFC2022, November 1996
[MPLS] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol
Label Switching Architecture", RFC3031, January 2001
[TEMIB] C. Srinivasan, A. Viswanathan, and T. Nadeau, "MPLS Traffic
Engineering Management Information Base", <draft-ietf-mpls-
te-mib-09.txt>, work in progress, Nov. 2002.
[PWE3_ARCH] S. Bryant and P. Pate, et. al., "PWE3 Architecture",
<draft-ietf-pwe3-arch-01.txt>, work in progress, Nov. 2002.
[RFC2401] S. Kent, R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, Nov. 1998.
[RTP] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC1889, January 1996.
[SMIV2] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser,
"Structure of Management Information for Version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
14. Authors' Addresses
XiPeng Xiao
Riverstone Networks
5200 Great America Parkway
Santa Clara, CA 95054
Email: xxiao@riverstonenet.com
Danny McPherson
TCB.net
Email: danny@tcb.net
Prayson Pate
Overture Networks
P. O. Box 14864
RTP, NC, USA 27709
Email: prayson.pate@overturenetworks.com
Vijay Gill
AOL Time Warner
EMail: vijaygill9@aol.com
Kireeti Kompella
Expires 06/03 Xiao/McPherson/Pate [Page 17]
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
Email: kireeti@juniper.net
Thomas D. Nadeau
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Email: tnadeau@cisco.com
Craig White
Level 3 Communications, LLC.
1025 Eldorado Blvd.
Broomfield, CO, 80021
Email: Craig.White@Level3.com
Expires 06/03 Xiao/McPherson/Pate [Page 18]
Internet Draft draft-ietf-pwe3-requirements-04 Dec. 2002
15. Full Copyright Section
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Expires 06/03 Xiao/McPherson/Pate [Page 19]
