idnits 2.17.00 (12 Aug 2021) /tmp/idnits41251/draft-ietf-pwe3-requirements-00.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 193: '...wire edge device MUST provide service ...' RFC 2119 keyword, line 197: '... service MUST specify what a PDU is....' RFC 2119 keyword, line 219: '... PWE3 approach SHOULD provide some m...' RFC 2119 keyword, line 222: '... REQUIRED or OPTIONAL, depending on ...' RFC 2119 keyword, line 226: '...eudo-wire header MUST be between the P...' (60 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 51 has weird spacing: '...n Edge to E...' == Line 58 has weird spacing: '...ulation of S...' == Line 88 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 'SHOULD not' in this paragraph: Timing information can be essential for the endpoints of a service. If the original frames contain timing information, the encapsulation mechanism SHOULD not cause loss of such timing information. Requirements on clock recovery between pseudo-wire endpoints are further discussed in the "Maintenance of Emulated Services" section. == 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: 6) The TTL fields of the encapsulated 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: No matter which protocol (e.g. GRE or L2TP or MPLS) is used for packet transport, PWE3 SHOULD just be an application of that protocol. In other words, no new protocol (GRE or L2TP or MPLS) operations SHOULD be introduced. For example, if an MPLS label switching operation is performed, a PWE3 approach SHOULD not require that the TTL field of the top label remains unchanged. (Otherwise, this label switching would be different from a normal MPLS label switching and would be considered as a new protocol operation). If any new operations are indeed introduced in a PWE3 approach, they MUST be clearly pointed out. -- 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: 'RTP' is defined on line 692, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CES' -- Possible downref: Non-RFC (?) normative reference: ref. 'MART1' -- Possible downref: Non-RFC (?) normative reference: ref. 'MART2' -- 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' Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 7 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-00.txt Photuris Inc. 3 Expires: November 17, 2001 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. 12 Requirements for 13 Pseudo Wire Emulation Edge-to-Edge (PWE3) 14 draft-ietf-pwe3-requirements-00.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC 2026. Internet-Drafts are 20 working documents of the Internet Engineering Task Force (IETF), its 21 areas, and its working groups. Note that other groups may also 22 distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document describes generic requirements for Pseudo-Wire 38 Emulation Edge to Edge. It provides guidelines for other working 39 group documents that will define mechanisms for providing pseudo-wire 40 emulation of specific services such as Ethernet, PPP, (Cisco) HDLC, 41 ATM, Frame Relay and TDM. It should be noted that the PWE3 Working 42 Group (WG) standardizes mechanisms that can be used to provide 43 pseudo-wire emulation services, but not the services themselves. 45 Copyright Notice 46 Copyright (C) The Internet Society (2001). All Rights Reserved. 48 Table of Contents 50 1 Introduction ................................................. 4 51 1.1 Reference Model of Pseudo-Wire Emulation Edge to Edge 52 (PWE3) .................................................... 4 53 1.2 Terminology ................................................ 5 54 2 PDU Encapsulation ............................................ 6 55 2.1 Conveyance of Necessary L2/L1 Header Information ........... 6 56 2.2 Location of the Pseudo-Wire Header ......................... 6 57 2.3 PDU Length ................................................. 6 58 2.4 Encapsulation of Signaling Messages of the Native 59 Services .................................................. 7 60 2.5 Timing Information ......................................... 7 61 2.6 Support for Circuit Multiplexing ........................... 7 62 2.7 Packet Ordering ............................................ 7 63 3 Packet Transport ............................................. 7 64 3.1 Setup of Pseudo-Wires ...................................... 7 65 3.2 Pseudo-Wire MTU ............................................ 8 66 3.3 Transport of Signaling Messages of the Native Services ..... 8 67 3.4 Transport Efficiency ....................................... 9 68 4 Faithfulness of Emulated Services ............................ 9 69 4.1 Characteristics of an Emulated Service ..................... 9 70 4.2 Service Quality of Emulated Services ....................... 10 71 4.3 Signaling of Native Services ............................... 10 72 5 Maintenance of Emulated Services ............................. 10 73 5.1 Signaling of Status Changes of an Emulated Service ......... 10 74 5.1.1 Up/Down Notification ..................................... 10 75 5.1.2 Packet Loss and/or Out-of-order Delivery ................. 11 76 5.1.3 Other Status Signaling ................................... 11 77 5.1.4 Collective Status Signaling .............................. 11 78 5.2 Clock Recovery ............................................. 12 79 6 Management of Emulated Services .............................. 12 80 6.1 MIB ........................................................ 12 81 6.2 Pseudo-Wire Traceroute ..................................... 12 82 7 Scalability .................................................. 12 83 8 Other Generic Requirements ................................... 13 84 9 Non-Requirements ............................................. 14 85 10 Quality of Service (QoS) Considerations ..................... 14 86 11 Inter-domain Pseudo-Wires ................................... 15 87 12 Security Considerations ..................................... 15 88 12.1 Security Considerations for the Signaling/Control 89 Channel ................................................... 15 90 12.2 Security Considerations for the Encapsulated PDUs ......... 15 91 13 Deployment Considerations ................................... 15 92 14 Acknowledgments ............................................. 15 93 15 References .................................................. 15 94 16 Authors' Addresses .......................................... 16 95 17 Full Copyright Section ...................................... 18 96 1. Introduction 98 1.1. Reference Model of Pseudo-Wire Emulation Edge to Edge (PWE3) 100 To provide pseudo-wire emulation, two end-services of the same type 101 are first configured between each service endpoint (SE) and the 102 corresponding PWE3 Edge (PE) device (See Figure 1). An end-service 103 is either: 104 - an Ethernet link between two ports or two VLANs, or 105 - a PPP link, or 106 - a (Cisco) HDLC link, or 107 - an ATM VC or VP, or 108 - a Frame Relay VC, or 109 - a TDM circuit. 110 A connection is then set up between the two PEs to connect these two 111 end-services. This connection is called a pseudo-wire in the PWE3 112 context. During the setup of a pseudo-wire, the two pseudo-wire 113 endpoints will exchange information about the service to be emulated 114 so that later they know how to handle packets coming from the other 115 end of the pseudo-wire. After the pseudo-wire is set up, layer-2 116 (e.g. Ethernet, ATM and Frame Relay) or layer-1 (e.g. SONET/SDH) PDUs 117 of frames from an end-service are encapsulated at the pseudo-wire 118 ingress. The encapsulated PDUs are then transported over the pseudo- 119 wire to the egress, where L2 or L1 header information is re- 120 constructed and the resulted frames are forwarded in their native 121 format to the other end-service. 123 |<--------- pseudo-wire -------->| 124 end- | | end- 125 +-----+ service +------+ +------+ service +-----+ 126 | SE1 |---------| PE1 |..................| PE2 |---------| SE2 | 127 +-----+ +------+ +------+ +-----+ 128 service PW endpoint 1 PW endpoint 2 service 129 endpoint 1 endpoint 2 130 | | 131 |<---------------- emulated service ---------------->| 133 Figure 1: Pseudo-Wire Reference Model 135 Different carriers may choose different types of pseudo-wires. For 136 example, carriers may choose to use GRE tunnels [GRE], L2TP tunnels 137 [L2TP], or MPLS LSPs [MPLS] as pseudo-wires. This document does not 138 assume that a particular type of pseudo-wires is used. Instead, it 139 describes generic requirements that apply to all pseudo-wires, for 140 all services including Ethernet, PPP, (Cisco) HDLC, ATM, Frame Relay 141 and TDM. 143 This document is not an introductory document. Readers are assumed to 144 be familiar with the PWE3 framework document [PATE], especially the 145 architecture assumptions stated in that document. 147 1.2. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119. 153 Below are the definitions for the terms used throughout the document. 155 End-Service An End-Service is either an Ethernet link 156 between two ports or two VLANs, or a PPP 157 link, or a (Cisco) HDLC link, or an ATM VC or 158 VP, or a Frame Relay VC, or a TDM circuit. 160 Pseudo-Wire Emulation Pseudo-Wire Emulation is an approach to 161 emulate the essential attributes of a service 162 over a packet network so that two remote 163 end-services appear directly connected by a 164 wire. 166 Emulated Service An Emulated Service is a service that is 167 provided via pseudo-wire emulation. 169 Service Endpoint A Service Endpoint (SE) is a device where one 170 end of an emulated service terminates. 172 Pseudo-Wire A Pseudo-Wire is a connection between two 173 end-services. 175 Pseudo-Wire Endpoint A Pseudo-Wire Endpoint is a device where one 176 end of a pseudo-wire terminates. 178 Path-oriented A Path-oriented Pseudo-Wire is a pseudo-wire 179 Pseudo-Wire for which core network devices must maintain 180 state information, for example, an MPLS LSP. 182 Non-path-oriented A Non-path-oriented Pseudo-Wire is a 183 Pseudo-Wire pseudo-wire for which core network devices 184 need not maintain state information, for 185 example, a L2TP tunnel. 187 Transport Tunnel A Transport Tunnel is a tunnel inside which 188 multiple pseudo-wires can be nested so that 189 they are transparent to core network devices. 191 2. PDU Encapsulation 193 Every pseudo-wire edge device MUST provide service interfaces to use 194 common service-specific techniques for encapsulating PDUs. It should 195 be noted that the PDUs to be encapsulated may or may not contain L2 196 or L1 header information. This is service specific. Every PWE3 197 service MUST specify what a PDU is. 199 A pseudo-wire header must contain sufficient but not excessive 200 information so that the other end of the pseudo-wire, aided with 201 information obtained during the pseudo-wire setup process, knows 202 exactly how to handle the encapsulated PDUs. A pseudo-wire header 203 consists of all the header fields in an encapsulated PDU that are 204 used by the pseudo-wire egress to determine how to handled the PDU. 205 The header that is used for transporting the encapsulated PDUs from 206 the pseudo-wire ingress to the egress (e.g. the tunnel label in 207 [MART2]) is not considered as part of the pseudo-wire header. It is 208 called transport header instead. It should be noted that transport 209 headers are totally different from transport-layer headers (e.g. 210 TCP/UDP headers). 212 Specific requirements on PDU encapsulation for a PWE3 approach are 213 listed below. 215 2.1. Conveyance of Necessary L2/L1 Header Information 217 Sometimes the egress of a pseudo-wire needs some L2 or L1 header 218 information in order to know how to process the PDUs received. A 219 PWE3 approach SHOULD provide some mechanism (e.g. using one or more 220 control words) for conveying such L2/L1 header information from the 221 pseudo-wire ingress to the egress. The use of these mechanisms can be 222 REQUIRED or OPTIONAL, depending on services. 224 2.2. Location of the Pseudo-Wire Header 226 A pseudo-wire header MUST be between the PDU and the transport 227 header. This is necessary for the pseudo-wire egress to locate the 228 pseudo-wire header, and to process the PDU. 230 2.3. PDU Length 232 A PWE3 approach MUST accommodate variable length PDUs, if variable 233 length PDUs are allowed by the native service. For example, a PWE3 234 approach for Frame Relay MUST accommodate variable length frames. 236 2.4. Encapsulation of Signaling Messages of the Native Services 238 PDUs that contain signaling information of the native service SHOULD 239 be encapsulated in the same way as data PDUs. This simplifies 240 handling at both the ingress and the egress of a pseudo-wire. 242 2.5. Timing Information 244 Timing information can be essential for the endpoints of a service. 245 If the original frames contain timing information, the encapsulation 246 mechanism SHOULD not cause loss of such timing information. 247 Requirements on clock recovery between pseudo-wire endpoints are 248 further discussed in the "Maintenance of Emulated Services" section. 250 2.6. Support for Circuit Multiplexing 252 If a service in its native form is capable of grouping multiple 253 circuits into a "trunk", e.g. an ATM VP, some mechanism SHOULD be 254 provided so that a single pseudo-wire can be used to connect two 255 end-trunks. From encapsulation perspective, the encapsulation header 256 MUST carry sufficient information, e.g. VCI of each cell, so that the 257 egress of the pseudo-wire can demultiplex individual circuits from 258 the pseudo-wire. 260 2.7. Packet Ordering 262 When packets carrying the encapsulated PDUs traverse a pseudo-wire, 263 they may arrive at the egress out of order. For some services, the 264 encapsulated PDUs must be delivered in order. For such services, some 265 mechanism MUST be provided to ensure that. Providing a sequence 266 number in the pseudo-wire header for each packet is one possible 267 approach. Every specific PWE3 approach MUST define as a mechanism if 268 in-order PDU delivery is required. 270 3. Packet Transport 272 This section describes requirements on how to transport packets 273 carrying the encapsulated PDUs over the network that provides PWE3 274 services. 276 3.1. Setup of Pseudo-Wires 278 A pseudo-wire is a tunnel that connects two end-services. After the 279 L2/L1 PDUs of a service are encapsulated, they must be transported 280 over the pseudo-wire to the other end-service. 282 Every PWE3 approach MUST define some signaling mechanism for setting 283 up the pseudo-wires. During the setup process, the pseudo-wire 284 endpoints need to exchange some information (e.g. learn each other's 285 capability). The signaling mechanism MUST enable the pseudo-wire 286 endpoints to exchange all necessary information. For example, both 287 endpoints must agree on an encapsulation method and the MTU size for 288 the pseudo-wire. As another example, in order to support circuit 289 multiplexing using ATM VPs, both pseudo-wire endpoints must agree on 290 using the VCIs in the encapsulated PDUs to demultiplex individual VCs 291 from the VP at the pseudo-wire egress. Which signaling protocol to 292 use and what information to exchange are service specific. Every PWE3 293 approach MUST specify these. Manual configuration can be considered 294 as a special kind of signaling and is explicitly allowed. 296 This document does not assume a particular type of pseudo-wires. GRE 297 tunnels, L2TP tunnels, or MPLS LSPs can all be used. Selection of a 298 particular type of pseudo-wires is carrier-dependent and is outside 299 scope of the PWE3 WG. 301 A pseudo-wire can be either path-oriented or non-path-oriented. The 302 difference is core network devices need to maintain state information 303 for path-oriented pseudo-wires (e.g. LSPs) but not for non-path- 304 oriented ones (e.g. GRE/L2TP tunnels). This has scalability 305 implication that is further discussed in the "Scalability" section. 307 3.2. Pseudo-Wire MTU 309 A pseudo-wire MUST be able to be configured with an MTU that is 310 sufficient to transport packets whose size equals to the largest PDU 311 size of the native service plus the pseudo-wire header and transport 312 header. At a pseudo-wire ingress, if a packet's length exceeds the 313 pseudo-wire MTU, it MUST be dropped. At a pseudo-wire egress, if the 314 length of a frame that is restored from a PDU exceeds the MTU of 315 destination end-service, it MUST be dropped. 317 3.3. Transport of Signaling Messages of the Native Services 319 Some native services use signaling messages for maintaining the 320 circuits. These signaling messages may be in-band, e.g. Ethernet flow 321 control or ATM performance management, or out-of-band, e.g. the 322 signaling VC of an ATM VP (from the perspective of other VCs in that 323 VP). If such signaling messages are lost, functionality of the 324 services will be significantly affected. Therefore, it can be 325 desirable to provide higher reliability for transporting signaling 326 messages. 328 Each PWE3 approach MAY state what approach can be used to ensure that 329 signaling messages of the native service will be delivered over the 330 network with high probability. Differentiating signaling packets from 331 data packets and giving them preferable forwarding treatment in the 332 network is one possible approach. Such approaches NEED not be 333 defined in a PWE3 approach itself. 335 3.4. Transport Efficiency 337 In order to reduce transport header overhead and increase bandwidth 338 efficiency, multiple PDUs MAY be concatenated before a transport 339 header is added. Each PDU still carries its own pseudo-wire header so 340 that the egress of the pseudo-wire knows how to handle it. 342 4. Faithfulness of Emulated Services 344 An emulated service SHOULD be as similar to the native service as 345 possible, but it is not REQUIRED that they should be identical. Each 346 difference between an emulated service and the corresponding native 347 service, if any, can be classified as either functional or non- 348 functional. Functional differences are those that cause some 349 features of the native service to become disabled in the emulated 350 one. For example, if an emulated Ethernet service introduces some 351 difference that can cause the Spanning Tree Protocol (STP) to mal- 352 function, such a difference will be classified as a functional 353 difference. Other differences are non-functional. For examples, 354 differences in service quality between an emulated service and the 355 native one are non-functional. In every PWE3 approach: 357 - All functional differences and the features disabled MUST be 358 pointed out; 360 - Non-functional differences SHOULD be pointed out. 362 Some basic requirements on faithfulness of an emulated service are 363 described below. 365 4.1. Characteristics of an Emulated Service 367 Functionally, two service endpoints that are connected by an emulated 368 service MUST appear directly connected by a native service, although 369 service quality of the emulated service may be different from that of 370 a native one. Specifically, this implies (but is not limited to) the 371 followings: 373 1) It MUST be possible to define type (e.g. Ethernet or PPP, which is 374 inherited from the native service), speed (e.g. 100Mbps), and MTU 375 size for an emulated service. 377 2) From the service endpoints' perspective, each emulated service 378 MUST appear as unshared. 380 3) If an emulated service fails (either at one of the end-services or 381 in the middle of the pseudo-wire), both service endpoints MUST be 382 notified reasonably timely. The definition of "reasonable 383 timeliness" is service-dependent. 385 4) Two service endpoints connected by an emulated service MUST be 386 able to establish routing protocol (e.g. IGP) adjacency over the 387 emulated service. To be clear, the Spanning Tree Protocol (STP) is 388 not considered as a routing protocol and requirements on 389 support/non-support of STP is outside scope of this document. 391 5) When desired, an emulated service MUST be able to appear as a 392 normal link in the service endpoints' IGP routing table. 394 6) The TTL fields of the encapsulated PDUs, if exist, MUST not be 395 changed inside an emulated service. 397 4.2. Service Quality of Emulated Services 399 It is RECOMMENDED but not REQUIRED that an emulated service provide 400 as high service quality as the native service. However, the PWE3 WG 401 only defines mechanisms for providing pseudo-wire emulation, not the 402 services themselves. What quality to provide for a specific emulated 403 service is a matter between a service provider (SP) and its 404 customers, and is outside scope of the PWE3 WG. In fact, different 405 SPs can use the same PWE3 approach but different QoS approaches to 406 provide the same emulated service with different service quality. 408 4.3. Signaling of Native Services 410 A PWE3 approach SHOULD support signaling of the native service. This 411 is further discussed in the "Maintenance of Emulated Services" 412 section. 414 5. Maintenance of Emulated Services 416 Every PWE3 approach MUST provide mechanisms for maintaining the 417 working condition of an emulated service and for signaling any status 418 changes. 420 5.1. Signaling of Status Changes of an Emulated Service 422 5.1.1. Up/Down Notification 424 With pseudo-wire emulation, a failure may occur at a remote place 425 such that one or both physical links between the SEs and PEs remains 426 up. For example in Figure 1, if the physical link between SE1 and 427 PE1 fails, the physical link between SE2 and PE2 will not be affected 428 and will remain up. Unless some signaling is done to notify SE2 of 429 the remote failure, SE2 will continue to send traffic over the 430 emulated service to SE1. Such traffic will be discarded at PE1. 431 Therefore, when an emulated service fails (either at an end-service 432 or in the middle of the pseudo-wire), both service endpoints MUST be 433 notified. Every PWE3 approach MUST provide such a signaling 434 mechanism. This functionality is equivalent to failure notification 435 of normal links. 437 Similarly, every PWE3 approach MUST provide some signaling mechanism 438 so that when a network failure is fixed, all the affected emulated 439 services will change status from "Down" to "Up". 441 5.1.2. Packet Loss and/or Out-of-order Delivery 443 A pseudo-wire can incur packet loss and/or out-of-order delivery. 444 This can significantly impact the working condition of an emulated 445 service. Number of packets lost or delivered out of order in unit 446 time can be considered as two new types of "generalized bit error 447 rate" of a pseudo-wire. Every PWE3 approach SHOULD provide some 448 mechanism so that if either type of "generalized bit error rate" 449 exceeds some configured threshold, the pseudo-wire and the emulated 450 service will be signaled down. 452 5.1.3. Other Status Signaling 454 A PWE3 approach MAY provide mechanism for other status signaling, if 455 any. 457 5.1.4. Collective Status Signaling 459 Status of a group of emulated services may be affected identically by 460 a single network incidence. For example, when the physical link 461 between a SE and a PE fails, all the emulated services that go 462 through that link will fail. It is likely that there exists a group 463 of emulated services which all terminate at a remote SE. (There can 464 be multiple such SEs). Therefore, it is desirable that a single 465 signaling message can be used to signal the failure of the whole 466 group of emulated services. A PWE3 approach MAY provide some 467 mechanism for signaling status changes of a group of emulated 468 circuits. One possible approach is to associate each emulated 469 service with a group ID when the pseudo-wire for that emulated 470 service is set up. Multiple emulated services can then be grouped by 471 associated them with identical group ID. In status signaling, that 472 group ID can then be used to refer all the emulated services in that 473 group. 475 5.2. Clock Recovery 477 For some services, the pseudo-wire endpoints need to maintain some 478 kind of timing relationship (e.g. synchronization). A PWE3 approach 479 for such services MUST provide some mechanism to support that. 481 6. Management of Emulated Services 483 Each PWE3 approach SHOULD provide some mechanisms for network 484 operators to manage the emulated service. 486 6.1. MIB 488 A pseudo-wire MIB (PW-MIB) MAY be provided for managing each emulated 489 service. The MIB SHOULD have the following requirements: 491 - The counters in the MIB SHOULD NOT replicate existing MIB counters. 493 - Each end-service SHOULD appear as an interface in the ifTable. 495 - The MIB SHOULD describe how the existing counters are used for 496 pseudo-wire emulation. 498 - The MIB MAY support row creation to create new end-service pairs. 500 - The MIB MAY augment existing tables. For example, the ifTable 501 SHOULD be augmented to provide counts of out-of-order packets. 503 - The MIB SHOULD define meanings for the standard linkUp and linkDown 504 traps, as well as any protocol-specific traps that are needed. 506 - The MIB SHOULD be structured in a hierarchical fashion such that 507 generic PW objects and tables are not duplicated for each service. 509 6.2. Pseudo-Wire Traceroute 511 It can be desirable to know the exact path of a pseudo-wire, 512 especially for troubleshooting purpose. A pseudo-wire emulation 513 service MAY support pseudo-wire traceroute, even if the pseudo-wire 514 used is non-path-oriented. 516 7. Scalability 518 Scalability requirements for Pseudo-Wire Emulation Edge to Edge are 519 described below. 521 - Pseudo-wire emulation services SHOULD be transparent to other 522 packet services (e.g. best effort Internet service). 524 - Only pseudo-wire endpoints should be aware of existence of pseudo- 525 wires and PWE3 services. Core network devices SHOULD NOT be exposed 526 to a large number of pseudo-wires. 528 Pseudo-wires can be path-oriented or non-path-oriented. For path- 529 oriented pseudo-wires, core network devices must maintain state 530 information for them. If a large number of path-oriented pseudo- 531 wires are used, core network devices will have to maintain a large 532 amount of state information. In order to avoid scalability problem, 533 transport tunnels between pseudo-wire endpoints can be introduced. 534 Pseudo-wires from the same ingress to the same egress are nested 535 inside the transport tunnel that is from that ingress to that 536 egress. By creating such a tunnel hierarchy, individual pseudo- 537 wires are transparent to the core devices. If a specific PWE3 538 approach uses path-oriented pseudo-wires, transport tunnels SHOULD 539 be used to improve scalability. However, a transport tunnel is not 540 part of any pseudo-wire. Signaling of transport tunnels NEED NOT be 541 defined in the PWE3 approach itself. As an example, if LSPs are 542 used as pseudo-wires in a PWE3 approach, they can be nested inside 543 a tunnel LSP from the pseudo-wire ingress to the pseudo-wire 544 egress. The tunnel LSPs can be signaled by any mechanism defined 545 in [MPLS]. 547 - Circuit multiplexing: circuit multiplexing SHOULD be supported. 549 - Collective status signaling: Collective status signaling SHOULD be 550 supported. 552 8. Other Generic Requirements 554 Other generic requirements for Pseudo-Wire Emulation Edge to Edge 555 include: 557 - No New Protocol Operations: 559 No matter which protocol (e.g. GRE or L2TP or MPLS) is used for 560 packet transport, PWE3 SHOULD just be an application of that 561 protocol. In other words, no new protocol (GRE or L2TP or MPLS) 562 operations SHOULD be introduced. For example, if an MPLS label 563 switching operation is performed, a PWE3 approach SHOULD not 564 require that the TTL field of the top label remains unchanged. 565 (Otherwise, this label switching would be different from a normal 566 MPLS label switching and would be considered as a new protocol 567 operation). If any new operations are indeed introduced in a PWE3 568 approach, they MUST be clearly pointed out. 570 - Minimum configuration work at the pseudo-wire endpoints; 572 - Easy to maintain and manage. 574 9. Non-Requirements 576 Some non-requirements are mentioned in various sections of this 577 document. Those work items are outside scope of the PWE3 WG. The 578 non-requirements are listed below: 580 - Selection of a particular type of pseudo-wires; 582 - Striving to make the emulated services perfectly match their native 583 services; 585 - Defining mechanisms for signaling the transport tunnels; 587 - Defining how to perform traffic management on packets that carry 588 encapsulated PDUs; 590 - Providing security for the encapsulated PDUs; 592 - Providing any multicast service that is not native to the emulated 593 medium. 595 To illustrate this point, Ethernet transmission to a multicast 596 IEEE-48 address is considered in scope, while multicast services 597 like [MARS] that are implemented on top of the medium are out of 598 scope; 600 10. Quality of Service (QoS) Considerations 602 In this document, QoS means satisfactory service quality. It should 603 not be confused with QoS mechanisms such as Weighted Fair Queueing 604 (WFQ) or Random Early Detection (RED). 606 QoS is essential for ensuring that the emulated services are similar 607 (but not necessarily identical) to their native forms. It is up to 608 network operators to decide how to provide QoS - They can choose to 609 rely on over-provisioning and/or deploy some QoS mechanisms. 611 In order to take advantage of some QoS mechanisms defined in other 612 working groups, e.g. the traffic management schemes defined in 613 DiffServ WG, it is desirable that some mechanisms exists for 614 differentiating the packets resulted from PDU encapsulation. These 615 mechanisms need not be defined in the PWE3 approaches themselves. For 616 example, if the resulted packets are MPLS or IP packets, their EXP or 617 DSCP fields can be used for marking and differentiating, 618 respectively. Every PWE3 approach SHOULD provide guidelines for 619 marking and differentiating, e.g. what fields in the original L2 or 620 L1 headers should be used for determining the EXP/DSCP value. But the 621 exact procedure on how to perform marking and differentiating, e.g. 622 the mapping from Ethernet .1P field to EXP field, is out of scope. 624 11. Inter-domain Pseudo-Wires 626 The PWE3 WG will determine the requirements for having a pseudo-wire 627 pass across an administrative boundary. An edge could be a native 628 hand-off or hand-off to a further pseudo-wire. The working group may 629 analyze requirements for both security and performance for the 630 inter-administration technology. This topic is for further study. 632 12. Security Considerations 634 12.1. Security Considerations for the Signaling/Control Channel 636 If a signaling/control channel is used in a PWE3 approach, some 637 security mechanism SHOULD be provided to ensure integrity of the 638 information transmitted across the signaling/control channel. 640 12.2. Security Considerations for the Encapsulated PDUs 642 Providing security for the encapsulated PDUs is outside scope of the 643 PWE3 WG. 645 13. Deployment Considerations 647 Transition from using separate networks for TDM, ATM, Frame Relay and 648 IP services to using a single network for multiple services requires 649 careful planning and execution. This is an important topic for 650 further study. 652 14. Acknowledgments 654 Some requirements specified in this document were originally 655 articulated in a number of documents including [MART1], [MART2], 656 [CES], and [SFBS]. The authors would like to acknowledge authors of 657 those documents. The authors would also like to acknowledge the input 658 and comments from T. So. 660 15. References 662 [CES] A. Malis et al, "SONET/SDH Circuit Emulation Service Over 663 MPLS (CEM) Encapsulation" , work in progress, April 2001. 666 [GRE] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, "Generic 667 Routing Encapsulation (GRE)", RFC2784, March 2000. 669 [L2TP] W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall, G. 670 Zorn, B. Palter, "Layer Two Tunneling Protocol (L2TP)", RFC 671 2661, August 1999. 673 [MARS] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based 674 ATM Networks", RFC2022, November 1996 676 [MART1] L. Martini et al, "Transport of Layer 2 Frames Over MPLS", 677 , work in 678 progress, May 2001. 680 [MART2] L. Martini et al, "Encapsulation Methods for Transport of 681 Layer 2 Frames Over MPLS", , work in progress, May 2001. 684 [MPLS] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol 685 Label Switching Architecture", RFC3031, January 2001 687 [PATE] P. Pate, X. Xiao, T. So, C. White, and K. Kompella, 688 "Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3)", 689 , work in progress, May 690 2001. 692 [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson "RTP: A 693 Transport Protocol for Real-Time Applications", RFC1889, 694 January 1996. 696 [SFBS] B. St-Denis, D. Fedyk, A. Bhatnagar, A. Siddiqui, R. 697 Hartani, and T. So "Multi-service over MPLS", , work in progress, Nov. 2000. 700 16. Authors' Addresses 702 XiPeng Xiao 703 Photuris, Inc. 704 2025 Stierlin Court 705 Mountain View, CA 94043 706 Email: xxiao@photuris.com 708 Danny McPherson 709 Amber Networks, Inc. 710 48664 Milmont Drive 711 Fremont, CA 94538 712 Email: danny@ambernetworks.com 713 Prayson Pate 714 Overture Networks 715 P. O. Box 14864 716 RTP, NC, USA 27709 717 Email: prayson.pate@overturenetworks.com 719 Craig White 720 Level 3 Communications, LLC. 721 1025 Eldorado Blvd. 722 Broomfield, CO, 80021 723 e-mail: Craig.White@Level3.com 725 Kireeti Kompella 726 Juniper Networks, Inc. 727 1194 N. Mathilda Ave. 728 Sunnyvale, CA 94089 729 Email: kireeti@juniper.net 730 17. Full Copyright Section 732 Copyright (C) The Internet Society (2000). All Rights Reserved. 734 This document and translations of it may be copied and furnished to 735 others, and derivative works that comment on or otherwise explain it 736 or assist in its implementation may be prepared, copied, published 737 and distributed, in whole or in part, without restriction of any 738 kind, provided that the above copyright notice and this paragraph are 739 included on all such copies and derivative works. However, this 740 document itself may not be modified in any way, such as by removing 741 the copyright notice or references to the Internet Society or other 742 Internet organizations, except as needed for the purpose of 743 developing Internet standards in which case the procedures for 744 copyrights defined in the Internet Standards process must be 745 followed, or as required to translate it into languages other than 746 English. 748 The limited permissions granted above are perpetual and will not be 749 revoked by the Internet Society or its successors or assigns. 751 This document and the information contained herein is provided on an 752 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 753 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 754 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 755 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 756 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.