Internet Draft XiPeng Xiao Document: draft-ietf-pwe3-requirements-01.txt Photuris Inc. Expires: January 2002 Danny McPherson Amber Networks Prayson Pate Overture Networks, Inc. Craig White Level 3 Communications, LLC. Kireeti Kompella Juniper Networks, Inc. Vijay Gill Metromedia Fiber Network, Inc. Thomas D. Nadeau Cisco Systems, Inc. Requirements for Pseudo-Wre Emulation Edge-to-Edge (PWE3) draft-ietf-pwe3-requirements-01.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 generic requirements for Pseudo-Wire Emulation Edge to Edge (PWE3). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of specific services such as Ethernet, ATM, Frame Relay, TDM, and MPLS. It should be noted that the PWE3 Working Group (PWE3 WG) standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves. Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 2]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 Table of Contents 1 Introduction ................................................. 4 1.1 Reference Model of PWE3 .................................... 4 1.2 Terminology ................................................ 5 2 PDU Encapsulation ............................................ 6 2.1 Conveyance of Necessary L2/L1 Header Information ........... 7 2.2 PDU Length ................................................. 7 2.3 Encapsulation of Control Messages of the Native Services ........................................................... 7 2.4 Support for Circuit Multiplexing ........................... 7 2.5 Packet Ordering ............................................ 7 2.6 Packet Duplication ......................................... 7 3 Carrying the PW PDUs over a Packet-Switched Network .......... 8 3.1 Setup of Pseudo-Wires ...................................... 8 3.2 Pseudo-Wire MTU ............................................ 8 3.3 Carrying Control Messages of the Native Services ........... 8 3.4 PSN Tunnel Header Overhead ................................. 9 4 Faithfulness of Emulated Services ............................ 9 4.1 Characteristics of an Emulated Service ..................... 9 4.2 Service Quality of Emulated Services ....................... 10 5 Maintenance of Emulated Services ............................. 10 5.1 Keep-alive ................................................. 10 5.2 Status Monitoring .......................................... 10 5.3 Notification of Status Changes ............................. 11 5.3.1 Up/Down Notification ..................................... 11 5.3.2 Misconnection and Payload Mistype ........................ 11 5.3.3 Packet Loss, Corruption, and Out-of-order Delivery ....... 11 5.3.4 Other Status Notification ................................ 11 5.3.5 Collective Status Notification ........................... 11 5.4 Clock Recovery ............................................. 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 Traceroute ..................................... 13 7 Scalability .................................................. 13 8 Other Generic Requirements ................................... 14 8.1 RFC 2914 Conformance ....................................... 14 9 Non-Requirements ............................................. 14 10 Quality of Service (QoS) Considerations ..................... 15 11 Inter-domain Pseudo-Wires ................................... 15 12 Security Considerations ..................................... 15 12.1 Security Considerations for the Signaling/Control Channel ................................................... 15 12.2 Security Considerations for the PW PDUs ................... 15 13 Deployment Considerations ................................... 16 14 Acknowledgments ............................................. 16 15 References .................................................. 16 16 Authors' Addresses .......................................... 17 Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 2]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 17 Full Copyright Section ...................................... 19 Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 3]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 1. Introduction 1.1. Reference Model of PWE3 To provide pseudo-wire emulation (PWE), two pseudo-wire end-services (PWESs) of the same type are first configured between each customer edge (CE) device and the corresponding provider edge (PE) device (See Figure 1). 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 TDM circuit, or - an MPLS LSP. A connection is then set up between the two PEs to connect these two PWESs. This connection is called a pseudo-wire (PW) in the PWE3 context. 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 the PW is set up, layer-2 (e.g. Ethernet, ATM, Frame Relay and MPLS) or layer-1 (e.g. SONET/SDH) PDUs from a PWES are encapsulated at the PW ingress. The encapsulated PDUs are then sent over the PW to the egress, where L2 or L1 headers are re- constructed and the resulted frames are forwarded in their native format to the other CE. |<------- 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 This document does not assume that a particular type of PWs is used. Instead, it describes generic requirements that apply to all PWs, for all services including Ethernet, ATM, Frame Relay, TDM and MPLS. Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 4]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 This document is not an introductory document. For an architecture overview of PWE3, readers should refer to the PWE3 framework document [PATE]. 1.2. 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. Below are the definitions for the terms used throughout the document. Packet Switched Network A Packet Switched Network (PSN) is a network using IP, MPLS or L2TP as the unit of switching. Pseudo Wire Emulation Edge to Edge Pseudo Wire Emulation Edge to Edge (PWE3) is a mechanism that emulates the essential attributes of a service (such as a T1 leased line or Frame Relay) over a PSN. Customer Edge A Customer Edge (CE) is a device where one end of an emulated service originates and terminates. The CE is not aware that it is using an emulated service rather than a "real" service. Provider Edge A Provider Edge (PE) is a device that provides PWE3 to a CE. Pseudo Wire A Pseudo Wire (PW) is a connection between two PEs carried over a PSN. The PE provides the adaptation between the CE and the PW. Pseudo Wire PDU A Pseudo Wire PDU (PW PDU) is a PDU sent on the PW that contains all of the data and control information necessary to provide the desired service. PSN Tunnel A PSN Tunnel is a tunnel inside which multiple PWs can be nested so that they are transparent to core network devices. Path-oriented PW A Path-oriented PW is a PW for which the network devices of the underlying PSN must Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 5]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 maintain state information. Non-path-oriented PW A Non-path-oriented PW is a PW for which the network devices of the underlying PSN need not maintain state information. 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. In general, since not all functions may be supported in one or other of the networks, the translation of PCI may be partial or non-existent. However, this should not result in any loss of user data since the payload is not affected by PCI conversion at the service interworking IWF. Network Interworking In Network Interworking, the PCI (Protocol Control Information) of the protocol and the payload information used in two similar networks are transferred transparently by an IWF of the PE across the PSN. Typically the IWF of the PE encapsulates the information which is transmitted by means of an adaptation function and transfers it transparently to the other network. 2. PDU Encapsulation Every PE MUST provide service interfaces to use common service- specific techniques for encapsulating PDUs from the PWESs. It should be noted that the PDUs to be encapsulated may or may not contain L2 or L1 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 header that is used for sending the PW PDUs from the PW ingress to the egress (e.g. the tunnel label in [MARTINI2]) is not considered as part of the PW header. It is called PSN tunnel header. Specific requirements on PDU encapsulation for a PWE3 approach are listed below. Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 6]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 2.1. Conveyance of Necessary L2/L1 Header Information The egress of a PW needs some information, e.g. which native service the PW PDUs belong to, and possibly some L2 or L1 header information, in order to know how to process the PDUs received. A PWE3 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. 2.2. PDU Length 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. 2.3. Encapsulation of Control Messages of the Native Services 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 need to do in this regard. 2.4. Support for Circuit Multiplexing If a service in its native form is capable of grouping multiple circuits into a "trunk", e.g. an ATM VP, some mechanism SHOULD be provided so that a single PW can be used to connect two end-trunks. From encapsulation perspective, the encapsulation header MUST carry sufficient information, e.g. VCI of each cell, so that the egress of the PW can demultiplex individual circuits from the PW. 2.5. Packet Ordering When packets carrying the PW PDUs traverse a PW, they may arrive at the egress out of order. For some services, the PW PDUs 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. 2.6. Packet Duplication In rare cases, packets traversing a PW may be duplicated. For some services, packet duplication is not allowed. For such services some mechanism MUST be provided to ensure that duplicated packets will not be delivered. The mechanism may or may not be the same as the mechanism used to ensure in-order packet delivery. Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 7]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 3. Carrying the PW PDUs over a Packet-Switched Network This section describes requirements on how to send packets carrying the PW PDUs over a packet-switched network (PSN) that provides PWE3 services. 3.1. Setup of Pseudo-Wires A PW is a tunnel that connects two PWESs. After the L2/L1 PDUs of a service are encapsulated, they must be sent over the PW to the other PWES. Every PWE3 approach MUST define some signaling mechanism for setting up the PWs. During the setup process, the PEs need to exchange some information (e.g. learn each other's capability). The signaling mechanism MUST enable the PEs to exchange all necessary information. For example, both endpoints must agree on an encapsulation method. As another example, in order to support circuit multiplexing using ATM VPs, both PEs must agree on using the VCIs in the PW PDUs to demultiplex individual VCs from the VP at the PW egress. Which signaling protocol to use and what information to exchange are service specific. Every PWE3 approach MUST specify these. Manual configuration can be considered as a special kind of signaling and is explicitly allowed. IP tunnels [MPLSINIP], sessions in a [L2TP] tunnel, or [MPLS] LSPs can all be used as PWs. Selection of a particular type of PWs is carrier-dependent and is outside scope of the PWE3 WG. 3.2. Pseudo-Wire MTU A PW MUST be able to be configured with an PW_MTU. One way to do this is to set the PW_MTU to (PW_Path_MTU - PW_header - PSN_tunnel_header). At a PW ingress, if a packet's length exceeds the PW_MTU, it MAY be dropped. In this case, the management plane of the ingress PE MAY be notified. Alternatively, a fragmentation mechanism MAY be defined and used. At a PW egress, if the length of a L2/L1 frame that is restored from a PW PDU exceeds the MTU of destination PWES, it MAY be dropped. In this case, the management plane of the egress PE MAY be notified. Alternatively, a fragmentation mechanism MAY be defined and used. 3.3. Carrying 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. If such control messages are lost, functionality of the services will be significantly affected. Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 8]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 Therefore, it can be desirable to provide higher reliability for carrying control messages. What mechanisms to use and how to use those mechanisms for providing higher reliability are outside scope of the PWE3 WG. 3.4. PSN Tunnel Header Overhead In order to reduce PSN tunnel header overhead, multiple PDUs MAY be concatenated before a PSN tunnel header is added. Each PDU still carries its own PW header so that the egress of the PW knows how to process it. However, the benefit of concatenating multiple PDUs for header efficiency should be weighed against the resulting larger penalty incurred by packet loss. 4. Faithfulness of Emulated Services An emulated service SHOULD be as similar to the native service as possible, but it is not REQUIRED that they should be identical. The applicability statement of a PWE3 service MUST report any limitations of the emulated service. All limitations between an emulated service and the corresponding native service can be classified as either functional or non-functional. Functional limitations are those that cause some features of the native service to become disabled in the emulated one. For example, if an emulated Ethernet service introduces some difference that can cause the Spanning Tree Protocol (STP) to malfunction, such a difference will be classified as a functional difference. Other differences are non-functional. For examples, differences in service quality between an emulated service and the native one are non-functional. Some basic requirements on faithfulness of an emulated service are described below. 4.1. Characteristics of an Emulated Service Functionally, two CEs that are connected by an emulated service SHOULD appear directly connected by a native 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 service. 2) The two endpoints of emulated service #1 and the two endpoints of emulated service #2 may be connected to the same PE at each end, respectively. As a result, the PWs of these two emulated services may share the same physical paths between the two PEs. But from Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 9]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 the CEs' perspective, each emulated service MUST appear as unshared, that is, a CE MUST NOT be aware of existence of other CEs or other emulated services. 3) If an emulated service 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 service, it MUST be possible to be established over an emulated service as well. Spanning Tree Protocol (STP) is not considered as a routing protocol and requirements on support/non- support of STP is outside scope of this document. 5) The TTL fields of the PW PDUs, if exist, MUST not be changed inside an emulated service. 4.2. Service Quality of Emulated Services It is RECOMMENDED but not REQUIRED that an emulated service provide as high service quality as the native service. However, 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. 5. Maintenance of Emulated Services Every PWE3 approach MUST provide mechanisms for maintaining the working condition of an emulated service. 5.1. Keep-alive If a native service has keep-alive mechanism, the corresponding emulated service MUST define a similar mechanism for keep-alive. 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] or [MPLSOAM], may be leveraged. Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 10]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 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 if any, 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 similar mechanism for doing so. 5.3.2. Misconnection and Payload Mistype With PWE3, misconnection and payload mistype can occur. A PWE3 approach MAY define some mechanism for detecting and handling misconnection and payload mistype. 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. Packet loss, corruption, and out-of-order delivery can be considered as "generalized bit error" of a 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 Status of a group of emulated services may be affected identically by a single network incidence. For example, when the physical link Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 11]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 between a CE and a PE fails, all the emulated services that go through that link will fail. It is likely that there exists a group of emulated services 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 services. 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 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 identical group ID. In status notification, that group ID can be used to refer all the emulated services in that group. 5.4. Clock Recovery For some services, the PEs need to maintain some kind of timing relationship (e.g. synchronization). The corresponding PWE3 services MUST provide some mechanism to support that. If time stamps need to be carried across the PSN, [RTP] MUST be used. 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 ifTable. Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 12]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 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 Traceroute It can be desirable to know the exact path of a PW, especially for troubleshooting purpose. A PW emulation service MUST support PW traceroute. One tunnel traceroute approach is defined in [BONICA]. 7. Scalability Scalability requirements for PWE3 are described below. - Only PEs should be aware of existence of PWs and PWE3 services. Core network devices SHOULD NOT be exposed to a large number of PWs. PWs can be path-oriented or non-path-oriented. For path-oriented PWs, core network devices must maintain state information for them. If a large number of path-oriented PWs are used, core network devices will have to maintain a large amount of state information. In order to avoid scalability problem, PSN tunnels between PEs can be introduced. PWs from the same ingress to the same egress are nested inside the PSN tunnel that is from that ingress to that egress. By creating such a tunnel hierarchy, individual PWs are transparent to the core devices. If a specific PWE3 approach uses path-oriented PWs, PSN tunnels SHOULD be used to improve Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 13]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 scalability. However, a PSN tunnel is not part of any PW. Signaling of PSN tunnels NEED NOT be defined in the PWE3 approach itself. As an example, if LSPs are used as PWs in a PWE3 approach, they can be nested inside a tunnel LSP from the PW ingress to the PW egress. The tunnel LSPs can be signaled by any mechanism defined in [MPLS]. - Circuit multiplexing: circuit multiplexing SHOULD be supported. - Collective status notification: collective status notification SHOULD be supported. 8. Other Generic Requirements 8.1. RFC 2914 Conformance [RFC2914] describes the need for congestion control in the Internet, and discusses what constitute correct congestion control. Any PWE3 approach MUST conform to RFC 2914 and be TCP-friendly in its response to congestion. The applicability document of a PWE3 approach MUST provide a statement on RFC 2914 conformance. 9. Non-Requirements Some non-requirements are mentioned in various sections of this document. Those work items are outside scope of the PWE3 WG. The non-requirements are listed below: - Service interworking; - Point-to-multipoint or multipoint-to-multipoint PWs; - 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. Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 14]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 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; 10. 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 the 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 guidelines for marking and differentiating, e.g. what fields in the original L2 or L1 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 .1P field to EXP field, is out of scope. 11. Inter-domain Pseudo-Wires The PWE3 WG will determine the requirements for having a PW pass across an administrative boundary. An edge could be a native hand- off or hand-off to a further PW. The working group may analyze requirements for both security and performance for the inter- administration technology. This topic is for further study. 12. Security Considerations 12.1. Security Considerations for the Signaling/Control Channel If a signaling/control channel is used in a PWE3 approach, some security mechanism MUST be provided to ensure integrity of the information transmitted across the signaling/control channel. 12.2. Security Considerations for the PW PDUs Providing security for the PW PDUs is outside scope of the PWE3 WG. Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 15]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 13. Deployment Considerations Transition from using separate networks for TDM, ATM, Frame Relay and IP services to using a single network for multiple services requires careful planning and execution. This is an important topic for further study. 14. Acknowledgments Some requirements specified in this document were originally articulated in a number of documents including [MARTINI1], [MARTINI2], [CES], and [SFBS]. The authors would like to acknowledge authors of those documents. The authors would also like to acknowledge the input and comments from Eric Rosen, Tricci So and Ron Cohen. 15. References [BONICA] R. Bonica, K. Kompella, and D. Meyer, "Tracing Requirements for Generic Tunnels", <draft-bonica-tunneltrace-01.txt>, work in progress, Feb. 2001. [CES] A. Malis et al, "SONET/SDH Circuit Emulation Service Over MPLS (CEM) Encapsulation" , work in progress, April 2001. [GRE] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, "Generic Routing Encapsulation (GRE)", RFC2784, March 2000. [IFMIB] K. McCloghrie, and F. Kastenholtz, "The Interfaces Group MIB using SMIv2", RFC 2233, Nov. 1997. [L2TP] W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall, G. Zorn, B. Palter, "Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999. [LSPPING] P. Pan, N. Sheth, and D. Cooper, "Detecting Data Plane Liveliness in RSVP-TE", <draft-pan-lsp-ping-00.txt>, work in progress, July 2001. [MARS] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC2022, November 1996 [MARTINI1] L. Martini et al, "Transport of Layer 2 Frames Over MPLS", <draft-martini-l2circuit-trans-MPLS-06.txt>, work in progress, May 2001. Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 16]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 [MARTINI2] L. Martini et al, "Encapsulation Methods for Transport of Layer 2 Frames Over MPLS", <draft-martini-l2circuit-encap- MPLS-02.txt>, work in progress, May 2001. [MPLS] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol Label Switching Architecture", RFC3031, January 2001 [MPLSINIP] P. Doolan, Y. Katsube, A. Malis, R. Wilder, T. Worster, "MPLS Label Stack Encapsulation in IP", <draft-worster- mpls-in-ip-04.txt>, work in progress, Feb. 2001. [MPLSOAM] N. Harrison, P. Willis, S. Davari, B. Mack-Crane, H. Ohta, "OAM Functionality for MPLS Networks", <draft-harrison- mpls-oam-00.txt>, work in progress, Feb. 2001. [TEMIB] C. Srinivasan, A. Viswanathan, and T. Nadeau, "MPLS Traffic Engineering Management Information Base Using SMIv2", <draft-ietf-mpls-te-mib-05.txt>, work in progress, November 2000. [PATE] P. Pate, X. Xiao, T. So, C. White, and K. Kompella, "Framework for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", <draft-pate-pwe3-framework-00.txt>, work in progress, May 2001. [RFC2914] S.Floyd, "Congestion Control Principles", RFC 2914, Sept. 2000. [RTP] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC1889, January 1996. [SFBS] B. St-Denis, D. Fedyk, A. Bhatnagar, A. Siddiqui, R. Hartani, and T. So, "Multi-service over MPLS", <draft- stdenis-ms-over-mpls-00.txt>, work in progress, Nov. 2000. [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. 16. Authors' Addresses XiPeng Xiao Photuris, Inc. 2025 Stierlin Court Mountain View, CA 94043 Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 17]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 Email: xxiao@photuris.com Danny McPherson Amber Networks, Inc. 48664 Milmont Drive Fremont, CA 94538 Email: danny@ambernetworks.com Prayson Pate Overture Networks P. O. Box 14864 RTP, NC, USA 27709 Email: prayson.pate@overturenetworks.com Craig White Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO, 80021 e-mail: Craig.White@Level3.com Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 Email: kireeti@juniper.net Vijay Gill Metromedia Fiber Network Inc. 8075 Leesburg Pike, Suite 300 Vienna, VA 22182 Email: vgill@mfnx.net Thomas D. Nadeau Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Email: tnadeau@cisco.com Expires 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 18]
Internet Draft draft-ietf-pwe3-requirements-01 July, 2001 17. 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 1/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau [Page 19]
