idnits 2.17.1 draft-ietf-pwe3-requirements-08.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 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 304: '... Every PE MUST provide an encapsulat...' RFC 2119 keyword, line 307: '... service MUST specify what the PDU i...' RFC 2119 keyword, line 320: '... approach MUST provide some mechanis...' RFC 2119 keyword, line 328: '... A PWE3 approach MUST accommodate vari...' RFC 2119 keyword, line 330: '... for Frame Relay MUST accommodate vari...' (50 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == 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) -- Obsolete informational reference (is this intentional?): RFC 2667 (ref. 'IPTUNMIB') (Obsoleted by RFC 4087) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 5 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-08.txt Riverstone Networks 3 Expires: Jun. 2004 4 Danny McPherson 5 Arbor Networks 7 Prayson Pate 8 Overture Networks 10 Editors 12 Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) 13 draft-ietf-pwe3-requirements-08.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC 2026. Internet-Drafts are 19 working documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes base requirements for the Pseudo-Wire 37 Emulation Edge to Edge Working Group (PWE3 WG). It provides 38 guidelines for other working group documents that will define 39 mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and 40 Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e. 41 "synchronous bit streams at rates defined by ITU G.702") are defined 42 in another document. It should be noted that the PWE3 WG standardizes 43 mechanisms that can be used to provide PWE3 services, but not the 44 services themselves. 46 Co-Authors 48 The following are co-authors of this document: 50 Vijay Gill AOL Time Warner, Inc. 51 Kireeti Kompella Juniper Networks, Inc. 52 Thomas D. Nadeau Cisco Systems 53 Craig White Level 3 Communications, LLC. 55 Copyright Notice 57 Copyright (C) The Internet Society (2002). All Rights Reserved. 59 Table of Contents 60 1 Terminology .................................................. 4 61 2 Introduction ................................................. 4 62 2.1 What Are Pseudo Wires? ..................................... 5 63 2.2 Current Network Architecture .............................. 5 64 2.3 PWE3 as a Path to Convergence .............................. 6 65 2.4 Suitable Applications for PWE3 ............................. 6 66 2.5 Summary .................................................... 7 67 3 Reference Model of PWE3 ...................................... 7 68 4 Packet Processing ............................................ 8 69 4.1 Encapsulation .............................................. 8 70 4.2 Frame Ordering ............................................. 9 71 4.3 Frame Duplication .......................................... 9 72 4.4 Fragmentation .............................................. 10 73 4.5 Consideration of Per-PSN Packet Overhead ................... 10 74 5 Maintenance of Emulated Services ............................. 10 75 5.1 Setup and Teardown of Pseudo-Wires ......................... 10 76 5.2 Handling Maintenance Message of the Native Services ........ 11 77 5.3 PE-initiated Maintenance Messages .......................... 11 78 6 Management of Emulated Services .............................. 13 79 6.1 MIBs ....................................................... 13 80 6.2 General MIB Requirements ................................... 13 81 6.3 Configuration and Provisioning ............................. 13 82 6.4 Performance Monitoring ..................................... 13 83 6.5 Fault Management and Notifications ......................... 14 84 6.6 Pseudo-Wire Connection Verification and Traceroute ........ 14 85 7 Faithfulness of Emulated Services ............................ 14 86 7.1 Characteristics of an Emulated Service ..................... 14 87 7.2 Service Quality of Emulated Services ....................... 15 88 8 Non-Requirements ............................................. 15 89 9 Quality of Service (QoS) Considerations ...................... 16 90 10 Inter-domain Issues ......................................... 16 91 11 Security Considerations ..................................... 17 92 12 Acknowledgments ............................................. 17 93 13 References .................................................. 17 94 13.1 Normative References ...................................... 17 95 13.2 Non-normative References .................................. 17 96 14 Authors' Addresses .......................................... 18 97 15 Full Copyright Section ...................................... 20 98 1. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119. 104 Some terms used throughout this document are listed below. 106 Attachment Circuit (AC) 107 The physical or virtual circuit attaching a CE to 108 a PE. An AC can be a Frame Relay DLCI, an ATM 109 VPI/VCI, an Ethernet port, a VLAN, a HDLC link, a 110 PPP connection on a physical interface, a PPP 111 session from an L2TP tunnel, an MPLS LSP, etc. 113 Customer Edge (CE) A device where one end of a service originates 114 and/or terminates. The CE is not aware that it is 115 using an emulated service rather than a native 116 service. 118 Packet Switched Network (PSN) 119 Within the context of PWE3, this is a network 120 using IP or MPLS as the mechanism for packet 121 forwarding. 123 Provider Edge (PE) A device that provides PWE3 to a CE. 125 Pseudo Wire (PW) A mechanism that carries the essential elements of 126 an emulated circuit from one PE to another PE over 127 a PSN. 129 Pseudo Wire Emulation Edge to Edge (PWE3) 130 A mechanism that emulates the essential attributes 131 of a service (such as a T1 leased line or Frame 132 Relay) over a PSN. 134 Pseudo Wire PDU A Protocol Data Unit (PDU) sent on the PW that 135 contains all of the data and control information 136 necessary to emulate the desired service. 138 PSN Tunnel A tunnel across a PSN inside which one or more PWs 139 can be carried. 141 2. Introduction 142 2.1. What Are Pseudo Wires? 144 Pseudo Wire Emulation Edge-to-Edge (PWE3) is a mechanism that 145 emulates the essential attributes of a service such as ATM, Frame 146 Relay or Ethernet over a Packet Switched Network (PSN). The required 147 functions of PWs include encapsulating service-specific PDUs arriving 148 at an ingress port, and carrying them across a path or tunnel, 149 managing their timing and order, and any other operations required to 150 emulate the behavior and characteristics of the service as faithfully 151 as possible. 153 From the customer perspective, the PW is perceived as an unshared 154 link or circuit of the chosen service. However, there may be 155 deficiencies that impede some applications from being carried on a 156 PW. These limitations should be fully described in the appropriate 157 service-specific documents and Applicability Statements. 159 2.2. Current Network Architecture 161 The following sections give some background on where networks are 162 today and why they are changing. It also talks about the motivation 163 to provide converged networks while continuing to support existing 164 services. Finally it discusses how PWs can be a solution for this 165 dilemma. 167 2.2.1. Multiple Networks 169 For any given service provider delivering multiple services, the 170 current infrastructure usually consists of parallel or "overlay" 171 networks. Each of these networks implements a specific service, such 172 as Frame Relay, Internet access, etc. This is expensive, both in 173 terms of capital expense and operational costs. Furthermore, the 174 presence of multiple networks complicates planning. Service providers 175 wind up asking themselves these questions: 176 - Which of my networks do I build out? 177 - How many fibers do I need for each network? 178 - How do I efficiently manage multiple networks? 180 A converged network helps service providers answer these questions in 181 a consistent and economical fashion. 183 2.2.2. Transition to a Packet-Optimized Converged Network 185 In order to maximize return on their assets and minimize their 186 operating costs, service providers often look to consolidate the 187 delivery of multiple service types onto a single networking 188 technology. 190 As packet traffic takes up a larger and larger portion of the 191 available network bandwidth, it becomes increasingly useful to 192 optimize public networks for the Internet Protocol. However, many 193 service providers are confronting several obstacles in engineering 194 packet-optimized networks. Although Internet traffic is the fastest 195 growing traffic segment, it does not generate the highest revenue per 196 bit. For example, Frame Relay traffic currently generates higher 197 revenue per bit than native IP services do. Private line TDM 198 services still generate even more revenue per bit than does Frame 199 Relay. In addition, there is a tremendous amount of legacy equipment 200 deployed within public networks that does not communicate using the 201 Internet Protocol. Service providers continue to utilize non-IP 202 equipment to deploy a variety of services, and see a need to 203 interconnect this legacy equipment over their IP-optimized core 204 networks. 206 2.3. PWE3 as a Path to Convergence 208 How do service providers realize the capital and operational benefits 209 of a new packet-based infrastructure, while leveraging the existing 210 equipment and also protecting the large revenue stream associated 211 with this equipment? How do they move from mature Frame Relay or ATM 212 networks, while still being able to provide these lucrative services? 214 One possibility is the emulation of circuits or services via PWs. 215 Circuit emulation over ATM and interworking of Frame Relay and ATM 216 have already been standardized. Emulation allows existing services to 217 be carried across the new infrastructure, and thus enables the 218 interworking of disparate networks. 220 Implemented correctly, PWE3 can provide a means for supporting 221 today's services over a new network. 223 2.4. Suitable Applications for PWE3 225 What makes an application suitable (or not) for PWE3 emulation? When 226 considering PWs as a means of providing an application, the following 227 questions must be considered: 228 - Is the application sufficiently deployed to warrant emulation? 229 - Is there interest on the part of service providers in providing an 230 emulation for the given application? 231 - Is there interest on the part of equipment manufacturers in 232 providing products for the emulation of a given application? 233 - Are the complexities and limitations of providing an emulation 234 worth the savings in capital and operational expenses? 235 If the answer to all four questions is "yes", then the application is 236 likely to be a good candidate for PWE3. Otherwise, there may not be 237 sufficient overlap between the customers, service providers, 238 equipment manufacturers and technology to warrant providing such an 239 emulation. 241 2.5. Summary 243 To maximize the return on their assets and minimize their operational 244 costs, many service providers are looking to consolidate the delivery 245 of multiple service offerings and traffic types onto a single IP- 246 optimized network. 248 In order to create this next-generation converged network, standard 249 methods must be developed to emulate existing telecommunications 250 formats such as Ethernet, Frame Relay, and ATM over IP-optimized core 251 networks. This document describes requirements for accomplishing 252 this goal. 254 3. Reference Model of PWE3 256 A pseudo-wire (PW) is a connection between two provider edge (PE) 257 devices which connects two attachment circuits (ACs). An AC can be a 258 Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, a HDLC 259 link, a PPP connection on a physical interface, a PPP session from an 260 L2TP tunnel, an MPLS LSP, etc. 262 |<------- Pseudo Wire ------>| 263 | | 264 | |<-- PSN Tunnel -->| | 265 V V V V 266 +----+ +----+ 267 +-----+ | PE1|==================| PE2| +-----+ 268 | |----------|............PW1.............|----------| | 269 | CE1 | | | | | | CE2 | 270 | |----------|............PW2.............|----------| | 271 +-----+ ^ | |==================| | +-----+ 272 ^ | +----+ +----+ ^ 273 | | Provider Edge 1 Provider Edge 2 | 274 | | | 275 | Attachment Circuit | 276 | | 277 |<-------------- Emulated Service ---------------->| 279 Customer Customer 280 Edge 1 Edge 2 282 Figure 1: PWE3 Reference Model 284 During the setup of a PW, the two PEs will be configured or will 285 automatically exchange information about the service to be emulated 286 so that later they know how to process packets coming from the other 287 end. After a PW is set up between two PEs, frames received by one PE 288 from an AC are encapsulated and sent over the PW to the remote PE, 289 where native frames are re-constructed and forwarded to the other CE. 290 For a detailed PWE3 architecture overview, readers should refer to 291 the PWE3 architecture document [PWE3_ARCH]. 293 This document does not assume that a particular type of PWs (e.g. 294 [L2TPv3] sessions or [MPLS] LSPs) or PSNs (e.g. IP or MPLS) is used. 295 Instead, it describes generic requirements that apply to all PWs and 296 PSNs, for all services including Ethernet, ATM, and Frame Relay, etc. 298 4. Packet Processing 300 This section describes data plane requirements for PWE3. 302 4.1. Encapsulation 304 Every PE MUST provide an encapsulation mechanism for PDUs from an AC. 305 It should be noted that the PDUs to be encapsulated may or may not 306 contain L2 header information. This is service specific. Every PWE3 307 service MUST specify what the PDU is. 309 A PW header consists of all the header fields in a PW PDU that are 310 used by the PW egress to determine how to process the PDU. The PSN 311 tunnel header is not considered as part of the PW header. 313 Specific requirements on PDU encapsulation are listed below. 315 4.1.1. Conveyance of Necessary L2 Header Information 317 The egress of a PW needs some information, e.g. which native service 318 the PW PDUs belong to, and possibly some L2 header information, in 319 order to know how to process the PDUs received. A PWE3 encapsulation 320 approach MUST provide some mechanism for conveying such information 321 from the PW ingress to the egress. It should be noted that not all 322 such information must be carried in the PW header of the PW PDUs. 323 Some information (e.g. service type of a PW) can be stored as state 324 information at the egress during PW setup. 326 4.1.2. Support of Variable Length PDUs 328 A PWE3 approach MUST accommodate variable length PDUs, if variable 329 length PDUs are allowed by the native service. For example, a PWE3 330 approach for Frame Relay MUST accommodate variable length frames. 332 4.1.3. Support of Multiplexing and Demultiplexing 334 If a service in its native form is capable of grouping multiple 335 circuits into a "trunk", e.g. multiple ATM VCCs in a VPC or multiple 336 Ethernet 802.1Q interfaces in a port, some mechanism SHOULD be 337 provided so that a single PW can be used to connect two end-trunks. 338 From encapsulation perspective, sufficient information MUST be 339 carried so that the egress of the PW can demultiplex individual 340 circuits from the PW. 342 4.1.4. Validation of PW-PDU 344 Most L2 frames have a checksum field to assure frame integrity. Every 345 PWE3 service MUST specify whether the frame's checksum should be 346 preserved across the PW, or should be removed at the ingress PE and 347 then be re-calculated and inserted at the egress PE. For protocols 348 such as ATM and FR, the checksum covers link-local information such 349 as the circuit identifiers (e.g. FR DLCI or ATM VPI/VCI). Therefore, 350 such checksum MUST be removed at the ingress PE and recalculated at 351 the egress PE. 353 4.1.5. Conveyance of Payload Type Information 355 Under some circumstances, it is desirable to be able to distinguish 356 PW traffic from other types of traffic such as IPv4 or IPv6 or OAM. 357 For example, if Equal Cost Multi-Path (ECMP) is employed in a PSN, 358 this additional distinguishability can be used to reduce the chance 359 that PW packets get misordered by the load balancing mechanism. Some 360 mechanism SHOULD provide this distinguishability if needed. Such 361 mechanism MAY be defined in the PWE3 WG or other WGs. 363 4.2. Frame Ordering 365 When packets carrying the PW PDUs traverse a PW, they may arrive at 366 the egress out of order. For some services, the frames (either 367 control frames only or both control and data frames) must be 368 delivered in order. For such services, some mechanism MUST be 369 provided for ensuring in-order delivery. Providing a sequence number 370 in the PW header for each packet is one possible approach to detect 371 out-of-order frames. Mechanisms for re-ordering frames may be 372 provided by Native Service Processing (NSP) [PWE3_ARCH] but are out 373 of scope of PWE3. 375 4.3. Frame Duplication 377 In rare cases, packets traversing a PW may be duplicated. For some 378 services, frame duplication is not allowed. For such services some 379 mechanism MUST be provided to ensure that duplicated frames will not 380 be delivered. The mechanism may or may not be the same as the 381 mechanism used to ensure in-order frame delivery. 383 4.4. Fragmentation 385 If the combined size of the L2 payload and its associated PWE3 and 386 PSN headers exceeds the PSN path MTU, the L2 payload may need to be 387 fragmented (Alternatively the L2 frame may be dropped). For certain 388 native service, fragmentation may also be needed to maintain a 389 control frame's relative position to the data frames (e.g. an ATM PM 390 cell's relative position). In general, fragmentation has a 391 performance impact. It is therefore desirable to avoid fragmentation 392 if possible. However, for different services, the need for 393 fragmentation can be different. When there is potential need for 394 fragmentation, each service-specific PWE3 document MUST specify 395 whether to fragment the frame in question or to drop it. If an 396 emulated service chooses to drop the frame, the consequence MUST be 397 specified in its applicability statement. 399 4.5. Consideration of Per-PSN Packet Overhead 401 When the L2 PDU size is small, in order to reduce PSN tunnel header 402 overhead, multiple PDUs MAY be concatenated before a PSN tunnel 403 header is added. Each encapsulated PDU still carries its own PW 404 header so that the egress PE knows how to process it. However, the 405 benefit of concatenating multiple PDUs for header efficiency should 406 be weighed against the resulting increase in delay, jitter and the 407 larger penalty incurred by packet loss. 409 5. Maintenance of Emulated Services 411 This section describes maintenance requirements for PWE3. 413 5.1. Setup and Teardown of Pseudo-Wires 415 A PW must be set up before an emulated circuit can be established, 416 and must be torn down when an emulated circuit is no longer needed. 417 Setup and teardown of a PW can be triggered by a command from the 418 management plane of a PE, or by Setup/Teardown of an AC (e.g., an ATM 419 SVC), or by an auto-discovery mechanism. 421 Every PWE3 approach MUST define some setup mechanism for establishing 422 the PWs. During the setup process, the PEs need to exchange some 423 information (e.g. to learn each other's capability). The setup 424 mechanism MUST enable the PEs to exchange all necessary information. 425 For example, both endpoints must agree on methods for encapsulating 426 PDUs and handling frame ordering. Which signaling protocol to use and 427 what information to exchange are service specific. Every PWE3 428 approach MUST specify them. Manual configuration of PWs can be 429 considered as a special kind of signaling and is allowed. 431 If a native circuit is bi-directional, the corresponding emulated 432 circuit can be signaled "Up" only when the associated PW and PSN 433 tunnels in both directions are functional. 435 5.2. Handling Maintenance Message of the Native Services 437 Some native services have mechanisms for maintenance purpose, e.g. 438 ATM OAM and FR LMI. Such maintenance messages can be in-band (i.e. 439 mixed with data messages in the same AC) or out-of-band (i.e. sent in 440 a dedicated control circuit). For such services, all in-band 441 maintenance messages related to a circuit SHOULD be transported in- 442 band just like data messages through the corresponding PW to the 443 remote CE. In other words, no translation is needed at the PEs for 444 in-band maintenance messages. In addition, it MAY be desirable to 445 provide higher reliability for maintenance messages. The mechanisms 446 for providing high reliability do not have to be defined in the PWE3 447 WG. 449 Out-of-band maintenance messages between a CE and a PE may relate to 450 multiple ACs between the CE and the PE. They need to be processed at 451 the local PE and possibly at the remote PE as well. If a native 452 service has some out-of-band maintenance messages, the corresponding 453 emulated service MUST specify how to process such messages at the 454 PEs. In general, an out-of-band maintenance message is either 455 translated into an in-band maintenance message of the native service 456 or a PWE-specific maintenance message for every AC related to that 457 out-of-band message. As an example, assume the ACs between a CE and a 458 PE are some ATM VCCs inside a VPC. When a F4 AIS [UNI3.0] from the CE 459 is received by the PE, the PE should translate that F4 AIS into a F5 460 AIS and send it to the remote CE for every VCC. Alternatively, the 461 PE should generate a PWE-specific maintenance message (e.g. label 462 withdrawal) to the remote PE for every VCC. When the remote PE 463 receives such a PWE-specific maintenance message, it may need to 464 generate a maintenance message of the native service and send it to 465 the attached CE. 467 5.3. PE-initiated Maintenance Messages 469 A PE needs to initiate some maintenance messages under some 470 circumstances without being triggered by any native maintenance 471 messages from the CE. These circumstances are usually caused by 472 fault, e.g. a PW failure in the PSN or a link failure between the CE 473 and the PE. 475 The reason the PEs need to initiate some maintenance messages under a 476 fault condition is because the existence of a PW between two CEs 477 would otherwise reduce the CEs' maintenance capability. This is 478 illustrated in the following example. If two CEs are directly 479 connected by a physical wire, a native service (e.g. ATM) can use 480 notifications from the lower layer (e.g. the physical link layer) to 481 assist its maintenance. For example, an ATM PVC can be signaled 482 "Down" if the physical wire fails. However, consider the following 483 scenario. 485 +-----+ Phy-link +----+ +----+ Phy-link +-----+ 486 | CE1 |----------| PE1|......PW......|PE2 |----------| CE2 | 487 +-----+ +----+ +----+ +-----+ 489 If the PW between PE1 and PE2 fails, CE1 and CE2 will not receive 490 physical link failure notification. As a result, they cannot declare 491 failure of the emulated circuit in a timely fashion, which will in 492 turn affect higher layer applications. Therefore, when the PW fails, 493 PE1 and PE2 need to initiate some maintenance messages to notify the 494 client layer on CE1 and CE2 that use the PW as a server layer. (In 495 this case, the client layer is the emulated service). Similarly, if 496 the physical link between PE1-CE1 fails, PE1 needs to initiate some 497 maintenance message(s) so that the client layer at CE2 will be 498 notified. PE2 may need to be involved in this process. 500 In the rare case when a physical wire between two CEs incurs many bit 501 errors, the physical link can be declared "Down" and the client layer 502 at the CEs be notified. Similarly, a PW can incur packet loss, 503 corruption, and out-of-order delivery. These can be considered as 504 "generalized bit error". Upon detection of excessive "generalized bit 505 error", a PW can be declared "Down" and the detecting PE needs to 506 initiate a maintenance message so that the client layer at the CE is 507 notified. 509 In general, every emulated service MUST specify: 510 * Under what circumstances PE-initiated maintenance messages are 511 needed, 512 * Format of the maintenance messages, and 513 * How to process the maintenance messages at the remote PE. 515 Some monitoring mechanisms are needed for detecting such 516 circumstances, e.g. a PW failure. Such mechanisms can be defined in 517 the PWE3 WG or elsewhere. 519 Status of a group of emulated circuits may be affected identically by 520 a single network incidence. For example, when the physical link 521 between a CE and a PE fails, all the emulated circuits that go 522 through that link will fail. It is desirable that a single 523 maintenance message be used to notify failure of the whole group of 524 emulated circuits connected to the same remote PE. A PWE3 approach 525 MAY provide some mechanism for notifying status changes of a group of 526 emulated circuits. One possible approach is to associate each 527 emulated circuit with a group ID while setting up the PW for that 528 emulated circuit. In a maintenance message, that group ID can be used 529 to refer to all the emulated circuits in that group. 531 If a PE needs to generate and send a maintenance message to a CE, the 532 PE MUST use a maintenance message of the native service. This is 533 essential in keeping the emulated service transparent to the CEs. 535 The requirements stated in this section are aligned with the ITU-T 536 maintenance philosophy for telecommunications networks [G805] (i.e. 537 client layer/server layer concept). 539 6. Management of Emulated Services 541 Each PWE3 approach SHOULD provide some mechanisms for network 542 operators to manage the emulated service. These mechanisms can be in 543 the forms described below. 545 6.1. MIBs 547 SNMP MIBs [SMIV2] MUST be provided for managing each emulated circuit 548 as well as pseudo-wire in general. These MIBs SHOULD be created with 549 the following requirements. 551 6.2. General MIB Requirements 553 New MIBs MUST augment or extend where appropriate, existing tables as 554 defined in other existing service-specific MIBs for existing services 555 such as MPLS or L2TP. For example, the ifTable as defined in the 556 Interface MIB [IFMIB] MUST be augmented to provide counts of out-of- 557 order packets. A second example is the extension of the MPLS-TE-MIB 558 [TEMIB] when emulating circuit services over MPLS. Rather than 559 redefining the tunnelTable so that PWE can utilize MPLS tunnels, for 560 example, entries in this table MUST instead be extended to add 561 additional PWE-specific objects. A final example might be to extend 562 the IP Tunnel MIB [IPTUNMIB] in such a way as to provide PWE3- 563 specific semantics when tunnels other than MPLS are used as PSN 564 transport. Doing so facilitates a natural extension of those objects 565 defined in the existing MIBs in terms of management, as well as 566 leveraging existing agent implementations. 568 An AC MUST appear as an interface in the ifTable. 570 6.3. Configuration and Provisioning 572 MIB Tables MUST be designed to facilitate configuration and 573 provisioning of the AC. 575 The MIB(s) MUST facilitate intra-PSN configuration and monitoring of 576 ACs. 578 6.4. Performance Monitoring 580 MIBs MUST collect statistics for performance and fault management. 582 MIBs MUST provide a description of how existing counters are used for 583 PW emulation and SHOULD not replicate existing MIB counters. 585 6.5. Fault Management and Notifications 587 Notifications SHOULD be defined where appropriate to notify the 588 network operators of any interesting situations, including faults 589 detected in the AC. 591 Objects defined to augment existing protocol-specific notifications 592 in order to add PWE functionality MUST explain how these 593 notifications are to be emitted. 595 6.6. Pseudo-Wire Connection Verification and Traceroute 597 For network management purpose, a connection verification mechanism 598 SHOULD be supported by PWs. Connection verification as well as other 599 alarming mechanisms can alert network operators that a PW has lost 600 its remote connection. It is sometimes desirable to know the exact 601 functional path of a PW for troubleshooting purpose, thus a 602 traceroute function capable of reporting the path taken by data 603 packets over the PW SHOULD be provided. 605 7. Faithfulness of Emulated Services 607 An emulated service SHOULD be as similar to the native service as 608 possible, but NOT REQUIRED to be identical. The applicability 609 statement of a PWE3 service MUST report limitations of the emulated 610 service. 612 Some basic requirements on faithfulness of an emulated service are 613 described below. 615 7.1. Characteristics of an Emulated Service 617 From the perspective of a CE, an emulated circuit is characterized as 618 an unshared link or circuit of the chosen service, although service 619 quality of the emulated service may be different from that of a 620 native one. Specifically, the following requirements MUST be met: 622 1) It MUST be possible to define type (e.g. Ethernet, which is 623 inherited from the native service), speed (e.g. 100Mbps), and MTU 624 size for an emulated circuit, if it is possible to do so for a 625 native circuit. 627 2) If the two endpoints CE1 and CE2 of emulated circuit #1 are 628 connected to PE1 and PE2, respectively, and CE3 and CE4 of 629 emulated circuit #2 are also connected to PE1 and PE2, then the 630 PWs of these two emulated circuits may share the same physical 631 paths between PE1 and PE2. But from each CE's perspective, its 632 emulated circuit MUST appear as unshared. For example, CE1/CE2 633 MUST NOT be aware of existence of emulated circuit #2 or CE3/CE4. 635 3) If an emulated circuit fails (either at one of the ACs or in the 636 middle of the PW), both CEs MUST be notified in a timely manner, 637 if they will be notified in the native service (see Section 5.3 638 for more information). The definition of "timeliness" is service- 639 dependent. 641 4) If a routing protocol (e.g. IGP) adjacency can be established over 642 a native circuit, it MUST be possible to be established over an 643 emulated circuit as well. 645 7.2. Service Quality of Emulated Services 647 It is NOT REQUIRED that an emulated service provide the same service 648 quality as the native service. The PWE3 WG only defines mechanisms 649 for providing PW emulation, not the services themselves. What quality 650 to provide for a specific emulated service is a matter between a 651 service provider (SP) and its customers, and is outside scope of the 652 PWE3 WG. 654 8. Non-Requirements 656 Some non-requirements are mentioned in various sections of this 657 document. Those work items are outside scope of the PWE3 WG. They are 658 summarized below: 660 - Service interworking; 662 In Service Interworking, the IWF (Interworking Function) between 663 two dissimilar protocols (e.g., ATM & MPLS, Frame Relay & ATM, ATM 664 & IP, ATM & L2TP, etc.) terminates the protocol used in one network 665 and translates (i.e. maps) its Protocol Control Information (PCI) 666 to the PCI of the protocol used in other network for User, Control 667 and Management Plane functions to the extent possible. 669 - Selection of a particular type of PWs; 671 - To make the emulated services perfectly match their native 672 services; 674 - Defining mechanisms for signaling the PSN tunnels; 676 - Defining how to perform traffic management on packets that carry PW 677 PDUs; 679 - Providing any multicast service that is not native to the emulated 680 medium. 682 To illustrate this point, Ethernet transmission to a multicast 683 IEEE-48 address is considered in scope, while multicast services 684 like [MARS] that are implemented on top of the medium are out of 685 scope; 687 9. Quality of Service (QoS) Considerations 689 Some native services such as ATM can offer higher service quality 690 than best effort Internet service. QoS is therefore essential for 691 ensuring that emulated services are compatible (but not necessarily 692 identical) to their native forms. It is up to network operators to 693 decide how to provide QoS - They can choose to rely on over- 694 provisioning and/or deploy some QoS mechanisms. 696 In order to take advantage of QoS mechanisms defined in other working 697 groups, e.g. the traffic management schemes defined in DiffServ WG, 698 it is desirable that some mechanisms exists for differentiating the 699 packets resulted from PDU encapsulation. These mechanisms do not have 700 to be defined in the PWE3 approaches themselves. For example, if the 701 resulted packets are MPLS or IP packets, their EXP or DSCP field can 702 be used for marking and differentiating. A PWE3 approach MAY provide 703 guidelines for marking and differentiating. 705 The applicability of PWE3 to a particular service depends on the 706 sensitivity of that service (or the CE implementation) to 707 delay/jitter etc and the ability of the application layer to mask 708 them. PWE3 may not be applicable to services that have severe 709 constraints in this respect. 711 10. Inter-domain Issues 713 PWE is a matter between the PW end-points and is transparent to the 714 network devices between the PW end-points. Therefore, inter-domain 715 PWE is fundamentally similar to intra-domain PWE. As long as PW 716 end-points use the same PWE approach, they can communicate 717 effectively, regardless of whether they are in the same domain. 718 Security may become more important in the inter-domain case and some 719 security measure such as end-point authentication MAY be applied. 720 QoS may become more difficult to deliver too, as one service provider 721 has no control over another service provider's provisioning and 722 traffic management policy. To solve the inter-domain QoS problem, 723 service providers have to cooperate. Once they agree at a contractual 724 level to provider high quality of service to certain traffic (e.g. 725 PWE traffic), the mechanisms defined in other working groups, e.g. 726 Diffserv WG, can be used. 728 Inter-domain PSN tunnels are generally more difficult to set up, tear 729 down and maintain than intra-domain ones. But that is an issue for 730 PSN tunneling protocols such as MPLS and L2TPv3 and is outside the 731 scope of PWE3. 733 11. Security Considerations 735 The PW end-point, PW demultiplexing mechanism, and the payloads of 736 the native service can all be vulnerable to attack. PWE3 should 737 leverage security mechanisms provided by the PW Demultiplexer or PSN 738 Layers. Such mechanisms SHOULD protect PW end-point and PW 739 Demultiplexer mechanism from denial-of-service (DoS) attacks and 740 spoofing of the native data units. Preventing unauthorized access to 741 PW end-points and other network devices is generally effective 742 against DoS attacks and spoofing, and can be part of protection 743 mechanism. Protection mechanisms SHOULD also address the spoofing of 744 tunneled PW data. The validation of traffic addressed to the PW 745 Demultiplexer end-point is paramount in ensuring integrity of PW 746 encapsulation. Security protocols such as IPSec [RFC2401] can be 747 used. 749 12. Acknowledgments 751 The authors would like to acknowledge input from M. Aissaoui, M. 752 Bocci, S. Bryant, R. Cohen, N. Harrison, G. Heron, T. Johnson, A. 753 Malis, L. Martini, E. Rosen, J. Rutemiller, T. So, Y. Stein and S. 754 Vainshtein. 756 13. References 758 13.1. Normative References 760 [IFMIB] K. McCloghrie, and F. Kastenholtz, "The Interfaces Group MIB 761 using SMIv2", RFC 2863, Jun. 2000. 763 [SMIV2] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, 764 "Structure of Management Information for Version 2 of the 765 Simple Network Management Protocol (SNMPv2)", RFC 2578, Apr. 766 1999. 768 13.2. Non-normative References 770 [G805] "Generic Functional Architecture of Transport Networks", 771 ITU-T Recommendation G.805, 2000. 773 [IPTUNMIB] D. Thaler, "IP Tunnel MIB", RFC2667, Aug. 1999. 775 [L2TPv3] J. Lau, M. Townsley, and I. Goyret, et. al., "Layer Two 776 Tunneling Protocol (Version 3)", , work in progress, Aug. 2003. 779 [MARS] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based 780 ATM Networks", RFC2022, November 1996 781 [MPLS] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol 782 Label Switching Architecture", RFC3031, January 2001 784 [PWE3_ARCH] S. Bryant and P. Pate, et. al., "PWE3 Architecture", 785 , work in progress, Oct. 2003. 787 [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the 788 Internet Protocol", RFC 2401, Nov. 1998. 790 [TEMIB] C. Srinivasan, A. Viswanathan, and T. Nadeau, "MPLS Traffic 791 Engineering Management Information Base", , work in progress, Aug. 2003. 794 [UNI3.0] ATM Forum, "ATM User-Network Interface Specification Version 795 3.0", Sept. 1993. 797 14. Authors' Addresses 799 XiPeng Xiao 800 Riverstone Networks 801 5200 Great America Parkway 802 Santa Clara, CA 95054 803 Email: xxiao@riverstonenet.com 805 Danny McPherson 806 Arbor Networks 807 Email: danny@arbor.net 809 Prayson Pate 810 Overture Networks 811 P. O. Box 14864 812 RTP, NC, USA 27709 813 Email: prayson.pate@overturenetworks.com 815 Vijay Gill 816 AOL Time Warner 817 EMail: vijaygill9@aol.com 819 Kireeti Kompella 820 Juniper Networks, Inc. 821 1194 N. Mathilda Ave. 822 Sunnyvale, CA 94089 823 Email: kireeti@juniper.net 825 Thomas D. Nadeau 826 Cisco Systems, Inc. 827 300 Beaver Brook Drive 828 Boxborough, MA 01719 829 Email: tnadeau@cisco.com 830 Craig White 831 Level 3 Communications, LLC. 832 1025 Eldorado Blvd. 833 Broomfield, CO, 80021 834 Email: Craig.White@Level3.com 835 15. Full Copyright Section 837 Copyright (C) The Internet Society (2000). All Rights Reserved. 839 This document and translations of it may be copied and furnished to 840 others, and derivative works that comment on or otherwise explain it 841 or assist in its implementation may be prepared, copied, published 842 and distributed, in whole or in part, without restriction of any 843 kind, provided that the above copyright notice and this paragraph are 844 included on all such copies and derivative works. However, this 845 document itself may not be modified in any way, such as by removing 846 the copyright notice or references to the Internet Society or other 847 Internet organizations, except as needed for the purpose of 848 developing Internet standards in which case the procedures for 849 copyrights defined in the Internet Standards process must be 850 followed, or as required to translate it into languages other than 851 English. 853 The limited permissions granted above are perpetual and will not be 854 revoked by the Internet Society or its successors or assigns. 856 This document and the information contained herein is provided on an 857 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 858 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 859 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 860 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 861 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.