idnits 2.17.00 (12 Aug 2021) /tmp/idnits30401/draft-ietf-pwe3-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 235: '... Every PE MUST provide service inter...' RFC 2119 keyword, line 239: '... service MUST specify what the PDU i...' RFC 2119 keyword, line 255: '... MUST provide some mechanism for con...' RFC 2119 keyword, line 263: '... A PWE3 approach MUST accommodate vari...' RFC 2119 keyword, line 265: '... for Frame Relay MUST accommodate vari...' (61 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 97 has weird spacing: '...rations for ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 5) The TTL fields of the PW PDUs, if exist, MUST not be changed inside an emulated service. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: MIBs MUST provide a description of how existing counters are used for PW emulation and SHOULD not replicate existing MIB counters. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'GRE' is defined on line 713, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BONICA' -- Possible downref: Non-RFC (?) normative reference: ref. 'CES' ** Obsolete normative reference: RFC 2233 (ref. 'IFMIB') (Obsoleted by RFC 2863) -- Possible downref: Non-RFC (?) normative reference: ref. 'LSPPING' -- Possible downref: Non-RFC (?) normative reference: ref. 'MARTINI1' -- Possible downref: Non-RFC (?) normative reference: ref. 'MARTINI2' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLSINIP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLSOAM' -- Possible downref: Non-RFC (?) normative reference: ref. 'TEMIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'PATE' ** Obsolete normative reference: RFC 1889 (ref. 'RTP') (Obsoleted by RFC 3550) -- Possible downref: Non-RFC (?) normative reference: ref. 'SFBS' ** Obsolete normative reference: RFC 1902 (ref. 'SMIV2') (Obsoleted by RFC 2578) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft XiPeng Xiao 2 Document: draft-ietf-pwe3-requirements-01.txt Photuris Inc. 3 Expires: January 2002 Danny McPherson 4 Amber Networks 5 Prayson Pate 6 Overture Networks, Inc. 7 Craig White 8 Level 3 Communications, LLC. 9 Kireeti Kompella 10 Juniper Networks, Inc. 11 Vijay Gill 12 Metromedia Fiber Network, Inc. 13 Thomas D. Nadeau 14 Cisco Systems, Inc. 16 Requirements for Pseudo-Wre Emulation Edge-to-Edge (PWE3) 17 draft-ietf-pwe3-requirements-01.txt 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC 2026. Internet-Drafts are 23 working documents of the Internet Engineering Task Force (IETF), its 24 areas, and its working groups. Note that other groups may also 25 distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet- Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document describes generic requirements for Pseudo-Wire 41 Emulation Edge to Edge (PWE3). It provides guidelines for other 42 working group documents that will define mechanisms for providing 43 pseudo-wire emulation of specific services such as Ethernet, ATM, 44 Frame Relay, TDM, and MPLS. It should be noted that the PWE3 Working 45 Group (PWE3 WG) standardizes mechanisms that can be used to provide 46 PWE3 services, but not the services themselves. 48 Copyright Notice 50 Copyright (C) The Internet Society (2001). All Rights Reserved. 52 Table of Contents 54 1 Introduction ................................................. 4 55 1.1 Reference Model of PWE3 .................................... 4 56 1.2 Terminology ................................................ 5 57 2 PDU Encapsulation ............................................ 6 58 2.1 Conveyance of Necessary L2/L1 Header Information ........... 7 59 2.2 PDU Length ................................................. 7 60 2.3 Encapsulation of Control Messages of the Native Services 61 ........................................................... 7 62 2.4 Support for Circuit Multiplexing ........................... 7 63 2.5 Packet Ordering ............................................ 7 64 2.6 Packet Duplication ......................................... 7 65 3 Carrying the PW PDUs over a Packet-Switched Network .......... 8 66 3.1 Setup of Pseudo-Wires ...................................... 8 67 3.2 Pseudo-Wire MTU ............................................ 8 68 3.3 Carrying Control Messages of the Native Services ........... 8 69 3.4 PSN Tunnel Header Overhead ................................. 9 70 4 Faithfulness of Emulated Services ............................ 9 71 4.1 Characteristics of an Emulated Service ..................... 9 72 4.2 Service Quality of Emulated Services ....................... 10 73 5 Maintenance of Emulated Services ............................. 10 74 5.1 Keep-alive ................................................. 10 75 5.2 Status Monitoring .......................................... 10 76 5.3 Notification of Status Changes ............................. 11 77 5.3.1 Up/Down Notification ..................................... 11 78 5.3.2 Misconnection and Payload Mistype ........................ 11 79 5.3.3 Packet Loss, Corruption, and Out-of-order Delivery ....... 11 80 5.3.4 Other Status Notification ................................ 11 81 5.3.5 Collective Status Notification ........................... 11 82 5.4 Clock Recovery ............................................. 12 83 6 Management of Emulated Services .............................. 12 84 6.1 MIBs ....................................................... 12 85 6.2 General MIB Requirements ................................... 12 86 6.3 Configuration and Provisioning ............................. 13 87 6.4 Performance Monitoring ..................................... 13 88 6.5 Fault Management and Notifications ......................... 13 89 6.6 Pseudo-Wire Traceroute ..................................... 13 90 7 Scalability .................................................. 13 91 8 Other Generic Requirements ................................... 14 92 8.1 RFC 2914 Conformance ....................................... 14 93 9 Non-Requirements ............................................. 14 94 10 Quality of Service (QoS) Considerations ..................... 15 95 11 Inter-domain Pseudo-Wires ................................... 15 96 12 Security Considerations ..................................... 15 97 12.1 Security Considerations for the Signaling/Control 98 Channel ................................................... 15 99 12.2 Security Considerations for the PW PDUs ................... 15 100 13 Deployment Considerations ................................... 16 101 14 Acknowledgments ............................................. 16 102 15 References .................................................. 16 103 16 Authors' Addresses .......................................... 17 104 17 Full Copyright Section ...................................... 19 105 1. Introduction 107 1.1. Reference Model of PWE3 109 To provide pseudo-wire emulation (PWE), two pseudo-wire end-services 110 (PWESs) of the same type are first configured between each customer 111 edge (CE) device and the corresponding provider edge (PE) device (See 112 Figure 1). A PWES is either: 113 - an Ethernet link or a VLAN link between two ports, or 114 - an ATM VC or VP, or 115 - a Frame Relay VC, or 116 - a TDM circuit, or 117 - an MPLS LSP. 118 A connection is then set up between the two PEs to connect these two 119 PWESs. This connection is called a pseudo-wire (PW) in the PWE3 120 context. During the setup of a PW, the two PEs will be configured or 121 will automatically exchange information about the service to be 122 emulated so that later they know how to process packets coming from 123 the other end. After the PW is set up, layer-2 (e.g. Ethernet, ATM, 124 Frame Relay and MPLS) or layer-1 (e.g. SONET/SDH) PDUs from a PWES 125 are encapsulated at the PW ingress. The encapsulated PDUs are then 126 sent over the PW to the egress, where L2 or L1 headers are re- 127 constructed and the resulted frames are forwarded in their native 128 format to the other CE. 130 |<------- Pseudo Wire ------>| 131 | | 132 | |<-- PSN Tunnel -->| | 133 PW V V V V PW 134 End Service+----+ +----+ End Service 135 +-----+ | | PE1|==================| PE2| | +-----+ 136 | |----------|............PW1.............|----------| | 137 | CE1 | | | | | | | | CE2 | 138 | |----------|............PW2.............|----------| | 139 +-----+ | | |==================| | | +-----+ 140 ^ +----+ +----+ | ^ 141 | Provider Edge 1 Provider Edge 2 | 142 | | 143 |<-------------- Emulated Service ---------------->| 145 Customer Customer 146 Edge 1 Edge 2 148 Figure 1: PWE3 Reference Model 150 This document does not assume that a particular type of PWs is used. 151 Instead, it describes generic requirements that apply to all PWs, for 152 all services including Ethernet, ATM, Frame Relay, TDM and MPLS. 154 This document is not an introductory document. For an architecture 155 overview of PWE3, readers should refer to the PWE3 framework document 156 [PATE]. 158 1.2. Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119. 164 Below are the definitions for the terms used throughout the document. 166 Packet Switched Network 167 A Packet Switched Network (PSN) is a network 168 using IP, MPLS or L2TP as the unit of 169 switching. 171 Pseudo Wire Emulation Edge to Edge 172 Pseudo Wire Emulation Edge to Edge (PWE3) is a 173 mechanism that emulates the essential 174 attributes of a service (such as a T1 leased 175 line or Frame Relay) over a PSN. 177 Customer Edge A Customer Edge (CE) is a device where one end 178 of an emulated service originates and 179 terminates. The CE is not aware that it is 180 using an emulated service rather than a "real" 181 service. 183 Provider Edge A Provider Edge (PE) is a device that provides 184 PWE3 to a CE. 186 Pseudo Wire A Pseudo Wire (PW) is a connection between two 187 PEs carried over a PSN. The PE provides the 188 adaptation between the CE and the PW. 190 Pseudo Wire PDU A Pseudo Wire PDU (PW PDU) is a PDU sent on the 191 PW that contains all of the data and control 192 information necessary to provide the desired 193 service. 195 PSN Tunnel A PSN Tunnel is a tunnel inside which multiple 196 PWs can be nested so that they are transparent 197 to core network devices. 199 Path-oriented PW A Path-oriented PW is a PW for which the 200 network devices of the underlying PSN must 201 maintain state information. 203 Non-path-oriented PW A Non-path-oriented PW is a PW for which the 204 network devices of the underlying PSN need not 205 maintain state information. 207 Service Interworking In Service Interworking, the IWF (Interworking 208 Function) between two dissimilar protocols 209 (e.g., ATM & MPLS, Frame Relay & ATM, ATM & IP, 210 ATM & L2TP, etc.) terminates the protocol used 211 in one network and translates (i.e. maps) its 212 Protocol Control Information (PCI) to the PCI 213 of the protocol used in other network for User, 214 Control and Management Plane functions to the 215 extent possible. In general, since not all 216 functions may be supported in one or other of 217 the networks, the translation of PCI may be 218 partial or non-existent. However, this should 219 not result in any loss of user data since the 220 payload is not affected by PCI conversion at 221 the service interworking IWF. 223 Network Interworking In Network Interworking, the PCI (Protocol 224 Control Information) of the protocol and the 225 payload information used in two similar 226 networks are transferred transparently by an 227 IWF of the PE across the PSN. Typically the IWF 228 of the PE encapsulates the information which is 229 transmitted by means of an adaptation function 230 and transfers it transparently to the other 231 network. 233 2. PDU Encapsulation 235 Every PE MUST provide service interfaces to use common service- 236 specific techniques for encapsulating PDUs from the PWESs. It should 237 be noted that the PDUs to be encapsulated may or may not contain L2 238 or L1 header information. This is service specific. Every PWE3 239 service MUST specify what the PDU is. 241 A PW header consists of all the header fields in a PW PDU that are 242 used by the PW egress to determine how to process the PDU. The header 243 that is used for sending the PW PDUs from the PW ingress to the 244 egress (e.g. the tunnel label in [MARTINI2]) is not considered as 245 part of the PW header. It is called PSN tunnel header. 247 Specific requirements on PDU encapsulation for a PWE3 approach are 248 listed below. 250 2.1. Conveyance of Necessary L2/L1 Header Information 252 The egress of a PW needs some information, e.g. which native service 253 the PW PDUs belong to, and possibly some L2 or L1 header information, 254 in order to know how to process the PDUs received. A PWE3 approach 255 MUST provide some mechanism for conveying such information from the 256 PW ingress to the egress. It should be noted that not all such 257 information must be carried in the PW header of the PW PDUs. Some 258 information (e.g. service type of a PW) can be stored as state 259 information at the egress during PW setup. 261 2.2. PDU Length 263 A PWE3 approach MUST accommodate variable length PDUs, if variable 264 length PDUs are allowed by the native service. For example, a PWE3 265 approach for Frame Relay MUST accommodate variable length frames. 267 2.3. Encapsulation of Control Messages of the Native Services 269 It is desirable that the PEs participate as little as possible in the 270 signaling and maintenance of the native services. However, it is up 271 to each specific PWE3 approach to specify what the PEs need to do in 272 this regard. 274 2.4. Support for Circuit Multiplexing 276 If a service in its native form is capable of grouping multiple 277 circuits into a "trunk", e.g. an ATM VP, some mechanism SHOULD be 278 provided so that a single PW can be used to connect two end-trunks. 279 From encapsulation perspective, the encapsulation header MUST carry 280 sufficient information, e.g. VCI of each cell, so that the egress of 281 the PW can demultiplex individual circuits from the PW. 283 2.5. Packet Ordering 285 When packets carrying the PW PDUs traverse a PW, they may arrive at 286 the egress out of order. For some services, the PW PDUs must be 287 delivered in order. For such services, some mechanism MUST be 288 provided for ensuring in-order delivery. Providing a sequence number 289 in the PW header for each packet is one possible approach. 291 2.6. Packet Duplication 293 In rare cases, packets traversing a PW may be duplicated. For some 294 services, packet duplication is not allowed. For such services some 295 mechanism MUST be provided to ensure that duplicated packets will not 296 be delivered. The mechanism may or may not be the same as the 297 mechanism used to ensure in-order packet delivery. 299 3. Carrying the PW PDUs over a Packet-Switched Network 301 This section describes requirements on how to send packets carrying 302 the PW PDUs over a packet-switched network (PSN) that provides PWE3 303 services. 305 3.1. Setup of Pseudo-Wires 307 A PW is a tunnel that connects two PWESs. After the L2/L1 PDUs of a 308 service are encapsulated, they must be sent over the PW to the other 309 PWES. 311 Every PWE3 approach MUST define some signaling mechanism for setting 312 up the PWs. During the setup process, the PEs need to exchange some 313 information (e.g. learn each other's capability). The signaling 314 mechanism MUST enable the PEs to exchange all necessary information. 315 For example, both endpoints must agree on an encapsulation method. As 316 another example, in order to support circuit multiplexing using ATM 317 VPs, both PEs must agree on using the VCIs in the PW PDUs to 318 demultiplex individual VCs from the VP at the PW egress. Which 319 signaling protocol to use and what information to exchange are 320 service specific. Every PWE3 approach MUST specify these. Manual 321 configuration can be considered as a special kind of signaling and is 322 explicitly allowed. 324 IP tunnels [MPLSINIP], sessions in a [L2TP] tunnel, or [MPLS] LSPs 325 can all be used as PWs. Selection of a particular type of PWs is 326 carrier-dependent and is outside scope of the PWE3 WG. 328 3.2. Pseudo-Wire MTU 330 A PW MUST be able to be configured with an PW_MTU. One way to do this 331 is to set the PW_MTU to (PW_Path_MTU - PW_header - 332 PSN_tunnel_header). At a PW ingress, if a packet's length exceeds the 333 PW_MTU, it MAY be dropped. In this case, the management plane of the 334 ingress PE MAY be notified. Alternatively, a fragmentation mechanism 335 MAY be defined and used. At a PW egress, if the length of a L2/L1 336 frame that is restored from a PW PDU exceeds the MTU of destination 337 PWES, it MAY be dropped. In this case, the management plane of the 338 egress PE MAY be notified. Alternatively, a fragmentation mechanism 339 MAY be defined and used. 341 3.3. Carrying Control Messages of the Native Services 343 Some native services use control messages for maintaining the 344 circuits. These control messages may be in-band, e.g. Ethernet flow 345 control or ATM performance management, or out-of-band, e.g. the 346 signaling VC of an ATM VP. If such control messages are lost, 347 functionality of the services will be significantly affected. 349 Therefore, it can be desirable to provide higher reliability for 350 carrying control messages. What mechanisms to use and how to use 351 those mechanisms for providing higher reliability are outside scope 352 of the PWE3 WG. 354 3.4. PSN Tunnel Header Overhead 356 In order to reduce PSN tunnel header overhead, multiple PDUs MAY be 357 concatenated before a PSN tunnel header is added. Each PDU still 358 carries its own PW header so that the egress of the PW knows how to 359 process it. However, the benefit of concatenating multiple PDUs for 360 header efficiency should be weighed against the resulting larger 361 penalty incurred by packet loss. 363 4. Faithfulness of Emulated Services 365 An emulated service SHOULD be as similar to the native service as 366 possible, but it is not REQUIRED that they should be identical. The 367 applicability statement of a PWE3 service MUST report any limitations 368 of the emulated service. All limitations between an emulated service 369 and the corresponding native service can be classified as either 370 functional or non-functional. Functional limitations are those that 371 cause some features of the native service to become disabled in the 372 emulated one. For example, if an emulated Ethernet service introduces 373 some difference that can cause the Spanning Tree Protocol (STP) to 374 malfunction, such a difference will be classified as a functional 375 difference. Other differences are non-functional. For examples, 376 differences in service quality between an emulated service and the 377 native one are non-functional. 379 Some basic requirements on faithfulness of an emulated service are 380 described below. 382 4.1. Characteristics of an Emulated Service 384 Functionally, two CEs that are connected by an emulated service 385 SHOULD appear directly connected by a native service, although 386 service quality of the emulated service may be different from that of 387 a native one. Specifically, the following requirements MUST be met: 389 1) It MUST be possible to define type (e.g. Ethernet, which is 390 inherited from the native service), speed (e.g. 100Mbps), and MTU 391 size for an emulated service. 393 2) The two endpoints of emulated service #1 and the two endpoints of 394 emulated service #2 may be connected to the same PE at each end, 395 respectively. As a result, the PWs of these two emulated services 396 may share the same physical paths between the two PEs. But from 397 the CEs' perspective, each emulated service MUST appear as 398 unshared, that is, a CE MUST NOT be aware of existence of other 399 CEs or other emulated services. 401 3) If an emulated service fails (either at one of the PWESs or in the 402 middle of the PW), both CEs MUST be notified in a timely manner, 403 if they will be notified in the native service. The definition of 404 "timeliness" is service-dependent. 406 4) If a routing protocol (e.g. IGP) adjacency can be established over 407 a native service, it MUST be possible to be established over an 408 emulated service as well. Spanning Tree Protocol (STP) is not 409 considered as a routing protocol and requirements on support/non- 410 support of STP is outside scope of this document. 412 5) The TTL fields of the PW PDUs, if exist, MUST not be changed 413 inside an emulated service. 415 4.2. Service Quality of Emulated Services 417 It is RECOMMENDED but not REQUIRED that an emulated service provide 418 as high service quality as the native service. However, the PWE3 WG 419 only defines mechanisms for providing PW emulation, not the services 420 themselves. What quality to provide for a specific emulated service 421 is a matter between a service provider (SP) and its customers, and is 422 outside scope of the PWE3 WG. In fact, different SPs can use the same 423 PWE3 approach with different QoS mechanisms to provide the same 424 emulated service with different service quality. 426 5. Maintenance of Emulated Services 428 Every PWE3 approach MUST provide mechanisms for maintaining the 429 working condition of an emulated service. 431 5.1. Keep-alive 433 If a native service has keep-alive mechanism, the corresponding 434 emulated service MUST define a similar mechanism for keep-alive. 436 5.2. Status Monitoring 438 Some native services have mechanisms for status monitoring. For 439 example, ATM supports OAM for this purpose. For such services, the 440 corresponding emulated services MUST specify how to perform status 441 monitoring. The mechanisms NEED NOT be defined in this WG. Some 442 status monitoring mechanisms defined in other WGs, e.g., [LSPPING] or 443 [MPLSOAM], may be leveraged. 445 5.3. Notification of Status Changes 447 5.3.1. Up/Down Notification 449 If a native service is bi-directional, the corresponding emulated 450 service can only be signaled up when the associated PWs, and PSN 451 tunnels if any, in both directions are functional. 453 Because the two CEs of an emulated service are not adjacent, a 454 failure may occur at a place such that one or both physical links 455 between the CEs and PEs remain up. For example in Figure 1, if the 456 physical link between CE1 and PE1 fails, the physical link between 457 CE2 and PE2 will not be affected and will remain up. Unless CE2 is 458 notified about the remote failure, it will continue to send traffic 459 over the emulated service to CE1. Such traffic will be discarded at 460 PE1. Some native services have failure notification so that when the 461 services fail, both CEs will be notified. For such native services, 462 the corresponding PWE3 service MUST provide a failure notification 463 mechanism. 465 Similarly, if a native service has notification mechanism so that 466 when a network failure is fixed, all the affected services will 467 change status from "Down" to "Up", the corresponding emulated service 468 MUST provide a similar mechanism for doing so. 470 5.3.2. Misconnection and Payload Mistype 472 With PWE3, misconnection and payload mistype can occur. A PWE3 473 approach MAY define some mechanism for detecting and handling 474 misconnection and payload mistype. 476 5.3.3. Packet Loss, Corruption, and Out-of-order Delivery 478 A PW can incur packet loss, corruption, and out-of-order delivery. 479 This can impact the working condition of an emulated service. Packet 480 loss, corruption, and out-of-order delivery can be considered as 481 "generalized bit error" of a PW. If a native service has some 482 mechanism to deal with bit error, the corresponding PWE3 service 483 SHOULD provide a similar mechanism. 485 5.3.4. Other Status Notification 487 A PWE3 approach MAY provide mechanism for other status notification, 488 if any. 490 5.3.5. Collective Status Notification 492 Status of a group of emulated services may be affected identically by 493 a single network incidence. For example, when the physical link 494 between a CE and a PE fails, all the emulated services that go 495 through that link will fail. It is likely that there exists a group 496 of emulated services which all terminate at a remote CE. (There can 497 be multiple such CEs). Therefore, it is desirable that a single 498 notification message be used to notify failure of the whole group of 499 emulated services. A PWE3 approach MAY provide some mechanism for 500 notifying status changes of a group of emulated circuits. One 501 possible approach is to associate each emulated service with a group 502 ID when the PW for that emulated service is set up. Multiple emulated 503 services can then be grouped by associating them with identical group 504 ID. In status notification, that group ID can be used to refer all 505 the emulated services in that group. 507 5.4. Clock Recovery 509 For some services, the PEs need to maintain some kind of timing 510 relationship (e.g. synchronization). The corresponding PWE3 services 511 MUST provide some mechanism to support that. If time stamps need to 512 be carried across the PSN, [RTP] MUST be used. 514 6. Management of Emulated Services 516 Each PWE3 approach SHOULD provide some mechanisms for network 517 operators to manage the emulated service. These mechanisms can be in 518 the forms described below. 520 6.1. MIBs 522 SNMP MIBs [SMIV2] MUST be provided for managing each emulated service 523 as well as pseudo-wire in general. These MIBs SHOULD be created with 524 the following requirements. 526 6.2. General MIB Requirements 528 New MIBs MUST augment or extend where appropriate, existing tables as 529 defined in other existing service-specific MIBs for existing services 530 such as MPLS or L2TP. For example, the ifTable as defined in the 531 Interface MIB [IFMIB] MUST be augmented to provide counts of out-of- 532 order packets. A second example is the extension of the MPLS-TE-MIB 533 [TEMIB] when emulating circuit services over MPLS. Rather than 534 redefining the tunnelTable so that PWES can utilize MPLS tunnels, for 535 example, entries in this table MUST instead be extended to add 536 additional PWES-specific objects. Doing so facilitates a natural 537 extension of those objects defined in the existing MIBs in terms of 538 management, as well as leveraging existing agent implementations. 540 Interfaces implementing a PWES MUST appear as an interface in the 541 ifTable. 543 6.3. Configuration and Provisioning 545 MIB Tables MUST be designed to facilitate configuration and 546 provisioning of the PWES. 548 The MIB(s) MUST facilitate intra-PSN configuration and monitoring of 549 PWES connections. 551 6.4. Performance Monitoring 553 MIBs MUST collect statistics for performance and fault management. 555 MIBs MUST provide a description of how existing counters are used for 556 PW emulation and SHOULD not replicate existing MIB counters. 558 6.5. Fault Management and Notifications 560 Notifications SHOULD be defined where appropriate to notify the 561 network operators of any interesting situations, including faults 562 detected in the PWES. 564 Objects defined to augment existing protocol-specific notifications 565 in order to add PWES functionality MUST explain how these 566 notifications are to be emitted. 568 6.6. Pseudo-Wire Traceroute 570 It can be desirable to know the exact path of a PW, especially for 571 troubleshooting purpose. A PW emulation service MUST support PW 572 traceroute. One tunnel traceroute approach is defined in [BONICA]. 574 7. Scalability 576 Scalability requirements for PWE3 are described below. 578 - Only PEs should be aware of existence of PWs and PWE3 services. 579 Core network devices SHOULD NOT be exposed to a large number of 580 PWs. 582 PWs can be path-oriented or non-path-oriented. For path-oriented 583 PWs, core network devices must maintain state information for them. 584 If a large number of path-oriented PWs are used, core network 585 devices will have to maintain a large amount of state information. 586 In order to avoid scalability problem, PSN tunnels between PEs can 587 be introduced. PWs from the same ingress to the same egress are 588 nested inside the PSN tunnel that is from that ingress to that 589 egress. By creating such a tunnel hierarchy, individual PWs are 590 transparent to the core devices. If a specific PWE3 approach uses 591 path-oriented PWs, PSN tunnels SHOULD be used to improve 592 scalability. However, a PSN tunnel is not part of any PW. 593 Signaling of PSN tunnels NEED NOT be defined in the PWE3 approach 594 itself. As an example, if LSPs are used as PWs in a PWE3 approach, 595 they can be nested inside a tunnel LSP from the PW ingress to the 596 PW egress. The tunnel LSPs can be signaled by any mechanism 597 defined in [MPLS]. 599 - Circuit multiplexing: circuit multiplexing SHOULD be supported. 601 - Collective status notification: collective status notification 602 SHOULD be supported. 604 8. Other Generic Requirements 606 8.1. RFC 2914 Conformance 608 [RFC2914] describes the need for congestion control in the Internet, 609 and discusses what constitute correct congestion control. Any PWE3 610 approach MUST conform to RFC 2914 and be TCP-friendly in its response 611 to congestion. The applicability document of a PWE3 approach MUST 612 provide a statement on RFC 2914 conformance. 614 9. Non-Requirements 616 Some non-requirements are mentioned in various sections of this 617 document. Those work items are outside scope of the PWE3 WG. The 618 non-requirements are listed below: 620 - Service interworking; 622 - Point-to-multipoint or multipoint-to-multipoint PWs; 624 - Selection of a particular type of PWs; 626 - Striving to make the emulated services perfectly match their native 627 services; 629 - Defining mechanisms for signaling the PSN tunnels; 631 - Defining how to perform traffic management on packets that carry PW 632 PDUs; 634 - Providing security for the PW PDUs; 636 - Providing any multicast service that is not native to the emulated 637 medium. 639 To illustrate this point, Ethernet transmission to a multicast 640 IEEE-48 address is considered in scope, while multicast services 641 like [MARS] that are implemented on top of the medium are out of 642 scope; 644 10. Quality of Service (QoS) Considerations 646 In this document, QoS means satisfactory service quality. It should 647 not be confused with QoS mechanisms such as Weighted Fair Queuing 648 (WFQ) or Random Early Detection (RED). 650 QoS is essential for ensuring that the emulated services are similar 651 (but not necessarily identical) to their native forms. It is up to 652 network operators to decide how to provide QoS - They can choose to 653 rely on over-provisioning and/or deploy some QoS mechanisms. 655 In order to take advantage of QoS mechanisms defined in other working 656 groups, e.g. the traffic management schemes defined in DiffServ WG, 657 it is desirable that some mechanisms exists for differentiating the 658 packets resulted from PDU encapsulation. These mechanisms need not be 659 defined in the PWE3 approaches themselves. For example, if the 660 packets are MPLS or IP packets, their EXP or DSCP fields can be used 661 for marking and differentiating. A PWE3 approach MAY provide 662 guidelines for marking and differentiating, e.g. what fields in the 663 original L2 or L1 headers should be used for determining the EXP/DSCP 664 value. But the exact procedure of how to perform marking and 665 differentiating, e.g. specifying the mapping function from Ethernet 666 .1P field to EXP field, is out of scope. 668 11. Inter-domain Pseudo-Wires 670 The PWE3 WG will determine the requirements for having a PW pass 671 across an administrative boundary. An edge could be a native hand- 672 off or hand-off to a further PW. The working group may analyze 673 requirements for both security and performance for the inter- 674 administration technology. This topic is for further study. 676 12. Security Considerations 678 12.1. Security Considerations for the Signaling/Control Channel 680 If a signaling/control channel is used in a PWE3 approach, some 681 security mechanism MUST be provided to ensure integrity of the 682 information transmitted across the signaling/control channel. 684 12.2. Security Considerations for the PW PDUs 686 Providing security for the PW PDUs is outside scope of the PWE3 WG. 688 13. Deployment Considerations 690 Transition from using separate networks for TDM, ATM, Frame Relay and 691 IP services to using a single network for multiple services requires 692 careful planning and execution. This is an important topic for 693 further study. 695 14. Acknowledgments 697 Some requirements specified in this document were originally 698 articulated in a number of documents including [MARTINI1], 699 [MARTINI2], [CES], and [SFBS]. The authors would like to acknowledge 700 authors of those documents. The authors would also like to 701 acknowledge the input and comments from Eric Rosen, Tricci So and Ron 702 Cohen. 704 15. References 706 [BONICA] R. Bonica, K. Kompella, and D. Meyer, "Tracing Requirements 707 for Generic Tunnels", , 708 work in progress, Feb. 2001. 710 [CES] A. Malis et al, "SONET/SDH Circuit Emulation Service Over 711 MPLS (CEM) Encapsulation" , work in progress, April 2001. 713 [GRE] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, "Generic 714 Routing Encapsulation (GRE)", RFC2784, March 2000. 716 [IFMIB] K. McCloghrie, and F. Kastenholtz, "The Interfaces Group MIB 717 using SMIv2", RFC 2233, Nov. 1997. 719 [L2TP] W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall, G. 720 Zorn, B. Palter, "Layer Two Tunneling Protocol (L2TP)", RFC 721 2661, August 1999. 723 [LSPPING] P. Pan, N. Sheth, and D. Cooper, "Detecting Data Plane 724 Liveliness in RSVP-TE", , work in 725 progress, July 2001. 727 [MARS] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based 728 ATM Networks", RFC2022, November 1996 730 [MARTINI1] L. Martini et al, "Transport of Layer 2 Frames Over MPLS", 731 , work in 732 progress, May 2001. 734 [MARTINI2] L. Martini et al, "Encapsulation Methods for Transport of 735 Layer 2 Frames Over MPLS", , work in progress, May 2001. 738 [MPLS] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol 739 Label Switching Architecture", RFC3031, January 2001 741 [MPLSINIP] P. Doolan, Y. Katsube, A. Malis, R. Wilder, T. Worster, 742 "MPLS Label Stack Encapsulation in IP", , work in progress, Feb. 2001. 745 [MPLSOAM] N. Harrison, P. Willis, S. Davari, B. Mack-Crane, H. Ohta, 746 "OAM Functionality for MPLS Networks", , work in progress, Feb. 2001. 749 [TEMIB] C. Srinivasan, A. Viswanathan, and T. Nadeau, "MPLS Traffic 750 Engineering Management Information Base Using SMIv2", 751 , work in progress, November 752 2000. 754 [PATE] P. Pate, X. Xiao, T. So, C. White, and K. Kompella, 755 "Framework for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", 756 , work in progress, May 757 2001. 759 [RFC2914] S.Floyd, "Congestion Control Principles", RFC 2914, Sept. 760 2000. 762 [RTP] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, 763 "RTP: A Transport Protocol for Real-Time Applications", 764 RFC1889, January 1996. 766 [SFBS] B. St-Denis, D. Fedyk, A. Bhatnagar, A. Siddiqui, R. 767 Hartani, and T. So, "Multi-service over MPLS", , work in progress, Nov. 2000. 770 [SMIV2] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, 771 "Structure of Management Information for Version 2 of the 772 Simple Network Management Protocol (SNMPv2)", RFC 1902, 773 January 1996. 775 16. Authors' Addresses 777 XiPeng Xiao 778 Photuris, Inc. 779 2025 Stierlin Court 780 Mountain View, CA 94043 781 Email: xxiao@photuris.com 783 Danny McPherson 784 Amber Networks, Inc. 785 48664 Milmont Drive 786 Fremont, CA 94538 787 Email: danny@ambernetworks.com 789 Prayson Pate 790 Overture Networks 791 P. O. Box 14864 792 RTP, NC, USA 27709 793 Email: prayson.pate@overturenetworks.com 795 Craig White 796 Level 3 Communications, LLC. 797 1025 Eldorado Blvd. 798 Broomfield, CO, 80021 799 e-mail: Craig.White@Level3.com 801 Kireeti Kompella 802 Juniper Networks, Inc. 803 1194 N. Mathilda Ave. 804 Sunnyvale, CA 94089 805 Email: kireeti@juniper.net 807 Vijay Gill 808 Metromedia Fiber Network Inc. 809 8075 Leesburg Pike, Suite 300 810 Vienna, VA 22182 811 Email: vgill@mfnx.net 813 Thomas D. Nadeau 814 Cisco Systems, Inc. 815 250 Apollo Drive 816 Chelmsford, MA 01824 817 Email: tnadeau@cisco.com 818 17. Full Copyright Section 820 Copyright (C) The Internet Society (2000). All Rights Reserved. 822 This document and translations of it may be copied and furnished to 823 others, and derivative works that comment on or otherwise explain it 824 or assist in its implementation may be prepared, copied, published 825 and distributed, in whole or in part, without restriction of any 826 kind, provided that the above copyright notice and this paragraph are 827 included on all such copies and derivative works. However, this 828 document itself may not be modified in any way, such as by removing 829 the copyright notice or references to the Internet Society or other 830 Internet organizations, except as needed for the purpose of 831 developing Internet standards in which case the procedures for 832 copyrights defined in the Internet Standards process must be 833 followed, or as required to translate it into languages other than 834 English. 836 The limited permissions granted above are perpetual and will not be 837 revoked by the Internet Society or its successors or assigns. 839 This document and the information contained herein is provided on an 840 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 841 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 842 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 843 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 844 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.