idnits 2.17.1 draft-ietf-pwe3-framework-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 518 has weird spacing: '...itching or br...' == Line 1149 has weird spacing: '...rks.com xipe...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- 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) == Missing Reference: 'LDPMIB' is mentioned on line 1028, but not defined == Unused Reference: 'L2TP' is defined on line 1045, but no explicit reference was found in the text == Unused Reference: 'IP' is defined on line 1055, but no explicit reference was found in the text == Unused Reference: 'CONGEST' is defined on line 1057, but no explicit reference was found in the text == Unused Reference: 'MALIS' is defined on line 1067, but no explicit reference was found in the text == Unused Reference: 'LDP-MIB' is defined on line 1107, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1889 (ref. 'RTP') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2558 (ref. 'SONETMIB') (Obsoleted by RFC 3592) ** Obsolete normative reference: RFC 1902 (ref. 'SMIv2') (Obsoleted by RFC 2578) == Outdated reference: A later version (-03) exists of draft-malis-pwe3-sonet-01 -- Possible downref: Normative reference to a draft: ref. 'MALIS' -- No information found for draft-pwe3-requirements - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'XIAO' == Outdated reference: A later version (-03) exists of draft-bonica-tunneltrace-02 -- Possible downref: Normative reference to a draft: ref. 'BONICA' == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-02 -- Possible downref: Normative reference to a draft: ref. 'PWMIB' -- Possible downref: Normative reference to a draft: ref. 'PWTCMIB' == Outdated reference: A later version (-02) exists of draft-danenberg-pw-cem-mib-01 -- Possible downref: Normative reference to a draft: ref. 'PWMPLSMIB' == Outdated reference: A later version (-14) exists of draft-ietf-mpls-lsr-mib-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'TEMIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'LDP-MIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'ATMCES' Summary: 8 errors (**), 0 flaws (~~), 16 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Prayson Pate, Editor 2 Document: draft-ietf-pwe3-framework-01.txt Overture Networks, Inc. 3 XiPeng Xiao 4 Redback Networks 5 Craig White Tricci So 6 Level 3 Communications, LLC. Caspian Networks 7 Kireeti Kompella Andrew G. Malis 8 Juniper Networks, Inc. Vivace Networks 9 Thomas K. Johnson Thomas D. Nadeau 10 Litchfield Communications Stewart Bryant 11 Cisco Systems 13 Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3) 14 draft-ietf-pwe3-framework-01.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 a framework for Pseudo Wire Emulation 38 Edge-to-Edge (PWE3). It discusses the emulation of services (such 39 Frame Relay, ATM, Ethernet T1, E1, T3, E3 and SONET/SDH) over packet 40 switched networks (PSNs) using IP or MPLS. It presents an 41 architectural framework for pseudo wires (PWs), defines terminology, 42 specifies the various protocol elements and their functions, 43 overviews some of the services that will be supported and discusses 44 how PWs fit into the broader context of protocols. 46 Copyright Notice 48 Copyright (C) The Internet Society (2002). All Rights Reserved. 50 Table of Contents 51 1 Introduction ................................................. 3 52 1.1 What Are Pseudo Wires? .................................... 3 53 1.2 Goals of This Document ..................................... 4 54 1.3 Non-Goals .................................................. 4 55 1.4 Terminology ................................................ 4 56 2 Background and Motivation .................................... 7 57 2.1 Current Network Architecture ............................... 7 58 2.2 PWE3 as a Path to Convergence .............................. 9 59 2.3 Suitable Applications for PWE3 ............................. 10 60 2.4 Summary .................................................... 10 61 3 Architecture of Pseudo Wires ................................. 10 62 3.1 Network Reference Model .................................... 11 63 3.2 Maintenance Reference Model ................................ 11 64 3.3 Maintenance Architecture ................................... 12 65 3.4 Protocol Stack Reference Model ............................. 12 66 3.5 Logical Protocol Layering Model ............................ 13 67 3.6 Architecture Assumptions ................................... 16 68 4 Design Considerations ........................................ 16 69 4.1 PW-PDU Validation .......................................... 16 70 4.2 PW-PDU Sequencing .......................................... 17 71 4.3 Session Multiplexing ....................................... 17 72 4.4 Security ................................................... 17 73 4.5 Encapsulation Control ...................................... 17 74 4.6 Statistics ................................................. 18 75 4.7 Traceroute ................................................. 18 76 4.8 Congestion Considerations .................................. 19 77 4.9 PW SNMP MIB Architecture ................................... 19 78 5 Acknowledgments .............................................. 21 79 6 References ................................................... 21 80 7 Security Considerations ...................................... 23 81 8 IANA Considerations .......................................... 23 82 9 Authors' Addresses ........................................... 23 83 10 Full Copyright Section ...................................... 24 84 1. Introduction 86 This document describes a framework for Pseudo Wire Emulation 87 Edge-to-Edge (PWE3). It discusses the emulation of services (such 88 Frame Relay, ATM, Ethernet T1, E1, T3, E3 and SONET/SDH) over packet 89 switched networks (PSNs) using IP or MPLS. It presents an 90 architectural framework for pseudo wires (PWs), defines terminology, 91 specifies the various protocol elements and their functions, 92 overviews the services supported and discusses how PWs fit into the 93 broader context of protocols. See [XIAO] for the requirements for 94 PWs. 96 1.1. What Are Pseudo Wires? 98 1.1.1. Definition 100 PWE3 is a mechanism that emulates the essential attributes of a 101 service (such as a T1 leased line or Frame Relay) over a PSN. The 102 required functions of PWs include encapsulating service-specific 103 bit-streams or PDUs arriving at an ingress port, and carrying them 104 across a path or tunnel, managing their timing and order, and any 105 other operations required to emulate the behavior and characteristics 106 of the service as faithfully as possible. 108 From the customer perspective, the PW is perceived as an unshared 109 link or circuit of the chosen service. However, there may be 110 deficiencies that impede some applications from being carried on a 111 PW. These limitations should be fully described in the appropriate 112 service-specific Encapsulation, Emulation and Maintenance Documents 113 (EEMDs) and Applicability Statements (ASes). 115 1.1.2. Functions 117 PWs provide the following functions in order to emulate the behavior 118 and characteristics of the desired service. 120 - Encapsulation of service-specific PDUs or circuit data arriving at 121 an ingress port (logical or physical). 123 - Carrying the encapsulated data across a tunnel. 125 - Managing the signaling, timing, order or other aspects of the 126 service at the boundaries of the PW. 128 - Service-specific status and alarm management. 130 EEMDs and/or ASes for each service will describe any shortfalls of 131 the emulation's faithfulness. 133 1.2. Goals of This Document 135 - Description of the motivation for creating PWs, and some background 136 on how they may be deployed. 138 - Description of an architecture and terminology for PWs. 140 - Description of the statistics and other network management 141 information needed for tunnel operation and management. 143 - Whenever possible, relevant requirements from existing IETF 144 documents and other sources will be incorporated by reference. 146 1.3. Non-Goals 148 The following are non-goals for this document: 150 - The detailed specification of the bits and bytes of the 151 encapsulations of the various services. This description is 152 contained in an EEMD and/or AS. 154 - The detailed definition of the protocols involved in PW setup and 155 maintenance. 157 The following are outside the scope of PWE3: 159 - Discussion of the protection of the encapsulated content of the PW. 161 - Any multicast service not native to the emulated medium. Thus, 162 Ethernet transmission to a "multicast" IEEE-48 address is in scope, 163 while multicast services like MARS that are implemented on top of 164 the medium are out of scope. 166 - Methods to signal or control the underlying PSN. 168 1.4. Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119. Below are 173 the definitions for the terms used throughout the document. 175 Packet Switched Network 176 A Packet Switched Network (PSN) is a network using 177 IP or MPLS as the unit of switching. 179 Pseudo Wire Emulation Edge to Edge 180 Pseudo Wire Emulation Edge to Edge (PWE3) is a 181 mechanism that emulates the essential attributes of 182 a service (such as a T1 leased line or Frame Relay) 183 over a PSN. 185 Customer Edge A Customer Edge (CE) is a device where one end of an 186 emulated service originates and terminates. The CE 187 is not aware that it is using an emulated service 188 rather than a "real" service. 190 Provider Edge A Provider Edge (PE) is a device that provides PWE3 191 to a CE. 193 Pseudo Wire A Pseudo Wire (PW) is a connection between two PEs 194 carried over a PSN. The PE provides the adaptation 195 between the CE and the PW. 197 PW End Service A Pseudo Wire End Service (PWES) is the interface 198 between a PE and a CE. This can be a physical 199 interface like a T1 or Ethernet, or a virtual 200 interface like a VC or VLAN. 202 Pseudo Wire PDU A Pseudo Wire PDU is a PDU sent on the PW that 203 contains all of the data and control information 204 necessary to provide the desired service. 206 PSN Tunnel A PSN Tunnel is a tunnel inside which multiple PWs 207 can be nested so that they are transparent to core 208 network devices. 210 PW Domain A PW Domain (PWD) is a collection of instances of 211 PWs that are within the scope of a single 212 homogeneous administrative domain (e.g. PW over MPLS 213 network or PW over IP network etc.). 215 Path-oriented PW A Path-oriented PW is a PW for which the network 216 devices of the underlying PSN must maintain path 217 state information. 219 Non-path-oriented PW 220 A Non-path-oriented PW is a PW for which the network 221 devices of the underlying PSN need not maintain path 222 state information. 224 Interworking Interworking is used to express interactions between 225 networks, between end systems, or between parts 226 thereof, with the aim of providing a functional 227 entity capable of supporting an end-to-end 228 communication. The interactions required to provide 229 a functional entity rely on functions and on the 230 means to select these functions. 232 Interworking Function 233 An Interworking Function (IWF) is a functional 234 entity that facilitates interworking between two 235 dissimilar networks (e.g., ATM & MPLS, ATM & L2TP, 236 etc.). A PE performs the IWF function. 238 Service Interworking 239 In Service Interworking, the IWF (Interworking 240 Function) between two dissimilar protocols (e.g., 241 ATM & MPLS, Frame Relay & ATM, ATM & IP, ATM & L2TP, 242 etc.) terminates the protocol used in one network 243 and translates (i.e. maps) its Protocol Control 244 Information (PCI) to the PCI of the protocol used in 245 other network for User, Control and Management Plane 246 functions to the extent possible. In general, since 247 not all functions may be supported in one or other 248 of the networks, the translation of PCI may be 249 partial or non-existent. However, this should not 250 result in any loss of user data since the payload is 251 not affected by PCI conversion at the service 252 interworking IWF. 254 Network Interworking 255 In Network Interworking, the PCI (Protocol Control 256 Information) of the protocol and the payload 257 information used in two similar networks are 258 transferred transparently by an IWF of the PE across 259 the PSN. Typically the IWF of the PE encapsulates 260 the information which is transmitted by means of an 261 adaptation function and transfers it transparently 262 to the other network. 264 Applicability Statement 265 Each PW service will have an Applicability Statement 266 (AS) that describes the applicability of PWs for 267 that service. 269 Encapsulation, Emulation and Maintenance Documents 270 Each PW service will have an Encapsulation, 271 Emulation and Maintenance Document (EEMDs) that 272 described the particulars of PWs for that service, 273 as well as the degree of faithfulness to that 274 service. 276 PSN Bound The traffic direction where information from a CE is 277 adapted to a PW, and PW-PDUs are sent into the PSN. 279 CE Bound The traffic direction where PW-PDUs are received on 280 a PW from the PSN, re-converted back in the emulated 281 service, and sent out to a CE. 283 CE Signaling CE (end-to-end) Signaling refers to messages sent 284 and received by the CEs. It may be desirable or 285 even necessary for the PE to participate in or 286 monitor this signaling in order to effectively 287 emulate the service. 289 PE/PW Maintenance 290 PE/PW Maintenance is used by the PEs to set up, 291 maintain and tear down the PW. It may be coupled 292 with CE signaling in order to effectively manage the 293 PW. 295 PSN Tunnel Signaling 296 PSN Tunnel Signaling is used to set up, maintain and 297 remove the underlying PSN tunnel. An example would 298 be LDP in MPLS for maintaining LSPs. 300 2. Background and Motivation 302 Why is anyone interested in PWs? This section gives some background 303 on where networks are today and why they are changing. It also talks 304 about the motivation to provide converged networks while continuing 305 to support existing services. Finally it discusses how PWs can be a 306 solution for this dilemma. 308 2.1. Current Network Architecture 310 2.1.1. Multiple Networks 312 For any given service provider delivering multiple services, the 313 current "network" usually consists of parallel or "overlay" networks. 314 Each of these networks implements a specific service, such as voice, 315 Frame Relay, Internet access, etc. This is quite expensive, both in 316 terms of capital expense as well as in operational costs. 317 Furthermore, the presence of multiple networks complicates planning. 318 Service providers wind up asking themselves these questions: 320 - Which of my networks do I build out? 322 - How many fibers do I need for each network? 324 - How do I efficiently manage multiple networks? 326 A converged network helps service providers answer these questions in 327 a consistent and economical fashion. 329 2.1.2. Convergence Today 331 There are some examples of convergence in today's network: 333 - Frame Relay is frequently carried over ATM networks using [FRF.5] 334 interworking. 336 - T1, E1 and T3 circuits are sometimes carried over ATM networks 337 using [ATMCES]. 339 - Voice is carried over ATM (using AAL2), Frame Relay (using FRF.11 340 VoFR), IP (using VoIP) and MPLS (using VoMPLS) networks. 342 Deployment of these examples range from limited (ATM CES) to fairly 343 common (FRF.5 interworking) to rapidly growing (VoIP). 345 2.1.3. The Emerging Converged Network 347 Many service providers are finding that the new IP-based and 348 MPLS-based switching systems are much less costly to acquire, deploy 349 and maintain than the systems that they replace. The new systems 350 take advantage of advances in technology in these ways: 352 - The newer systems leverage mass production of ASICs and optical 353 interfaces to reduce capital expense. 355 - The bulk of the traffic in the network today originates from packet 356 sources. Packet switches can economically switch and deliver this 357 traffic natively. 359 - Variable-length switches have lower system costs than ATM due to 360 simpler switching mechanisms as well as elimination of segmentation 361 and reassembly (SAR) at the edges of the network. 363 - Deployment of services is simpler due to the connectionless nature 364 of IP services or the rapid provisioning of MPLS applications. 366 2.1.4. Transition to a Packet-Optimized Converged Network 368 The greatest assets for many service providers are the physical 369 communications links that they own. The time and costs associated 370 with acquiring the necessary rights of way, getting the required 371 governmental approvals, and physically installing the cabling over a 372 variety of terrains and obstacles represents a significant asset that 373 is difficult to replace. Their greatest on-going costs are the 374 operational expenses associated with maintaining and operating their 375 networks. In order to maximize the return on their assets and 376 minimize their operating costs, service providers often look to 377 consolidate the delivery of multiple service types onto a single 378 networking technology. 380 The first generation converged network was based on TDM 381 (time-division multiplexing) technology. Voice, video, and data 382 traffic have been carried successfully across TDM/DACS-based networks 383 for decades. TDM technology has some significant drawbacks as a 384 converged networking technology. Operational costs for TDM networks 385 remain relatively high because the provisioning of end-to-end TDM 386 circuits is typically a tedious and labor-intensive task. In 387 addition, TDM switching does not make the best use of the 388 communications links. This is because fixed assignment of timeslots 389 does not allow for the statistical multiplexing of bursty data 390 traffic (i.e. temporarily unused bandwidth on one timeslot cannot be 391 dynamically re-allocated to another service). 393 The second generation of converged network was based on ATM 394 technology. Today many service providers convert voice, video, and 395 data traffic into fixed-length cells for carriage across ATM-based 396 networks. ATM improves upon TDM technology by providing the ability 397 to statistically multiplex different types of traffic onto 398 communications links. In addition, ATM SPVC technology is often used 399 to automatically provision end-to-end services, providing an 400 additional advantage over traditional TDM networks. However, ATM has 401 several significant drawbacks. One of the most frequently cited 402 problems with ATM is the so-called cell-tax, which refers to the 5 403 bytes out of 53 used as an ATM cell header. Another significant 404 problem with ATM is the AAL5 SAR, which becomes extremely difficult 405 to implement above 1 Gbps. There are also issues with the long-term 406 scalability of ATM, especially as a switching layer beneath IP. 408 As packet traffic takes up a larger and larger portion of the 409 available network bandwidth, it becomes increasingly useful to 410 optimize public networks for the Internet Protocol. However, many 411 service providers are confronting several obstacles in engineering 412 packet-optimized networks. Although Internet traffic is the fastest 413 growing traffic segment, it does not generate the highest revenue per 414 bit. For example, Frame Relay traffic currently generates a higher 415 revenue per bit than do native IP services. Private line TDM 416 services still generate even more revenue per bit than does Frame 417 Relay. In addition, there is a tremendous amount of legacy equipment 418 deployed within public networks that does not communicate using the 419 Internet Protocol. Service providers continue to utilize non-IP 420 equipment to deploy a variety of services, and see a need to 421 interconnect this legacy equipment over their IP-optimized core 422 networks. 424 2.2. PWE3 as a Path to Convergence 426 How do service providers realize the capital and operational benefits 427 of a new packet-based infrastructure, while leveraging the existing 428 base of SONET (Synchronous Optical Network) gear, and while also 429 protecting the large revenue stream associated with this equipment? 430 How do they move from mature Frame Relay or ATM networks, while still 431 being able to provide these lucrative services? 433 One possibility is the emulation of circuits or services via PWs. 434 Circuit emulation over ATM and interworking of Frame Relay and ATM 435 have already been standardized. Emulation allows existing services 436 to be carried across the new infrastructure, and thus enables the 437 interworking of disparate networks. [ATMCES] provides some insight 438 into the requirements for such a service: 440 There is a user demand for carrying certain types of 441 constant bit rate (CBR) or "circuit" traffic over 442 Asynchronous Transfer Mode (ATM) networks. As ATM is 443 essentially a packet- rather than circuit-oriented 444 transmission technology, it must emulate circuit 445 characteristics in order to provide good support for CBR 446 traffic. 448 A critical attribute of a Circuit Emulation Service (CES) 449 is that the performance realized over ATM should be 450 comparable to that experienced with the current PDH/SDH 451 technology. 453 Implemented correctly, PWE3 can provide a means for supporting 454 today's services over a new network. 456 2.3. Suitable Applications for PWE3 458 What makes an application suitable (or not) for PWE3 emulation? When 459 considering PWs as a means of providing an application, the following 460 questions must be considered: 462 - Is the application sufficiently deployed to warrant emulation? 464 - Is there interest on the part of service providers in providing an 465 emulation for the given application? 467 - Is there interest on the part of equipment manufacturers in 468 providing products for the emulation of a given application? 470 - Are the complexities and limitations of providing an emulation 471 worth the savings in capital and operational expenses? 473 If the answer to all four questions is "yes", then the application is 474 likely to be a good candidate for PWE3. Otherwise, there may not be 475 sufficient overlap between the customers, service providers, 476 equipment manufacturers and technology to warrant providing such an 477 emulation. 479 2.4. Summary 481 To maximize the return on their assets and minimize their operational 482 costs, many service providers are looking to consolidate the delivery 483 of multiple service offerings and traffic types onto a single 484 IP-optimized network. 486 In order to create this next-generation converged network, standard 487 methods must be developed to emulate existing telecommunications 488 formats such as Ethernet, Frame Relay, ATM, and TDM over IP-optimized 489 core networks. This document describes a framework accomplishing 490 this goal. 492 3. Architecture of Pseudo Wires 493 3.1. Network Reference Model 495 Figure 1 below shows the network reference model for PWs. As shown, 496 the PW provides an emulated service between the customer edges (CEs). 498 |<------- Pseudo Wire ------>| 499 | |<-- PSN Tunnel -->| | 500 PW V V V V PW 501 End Service +----+ +----+ End Service 502 +-----+ | | PE1|==================| PE2| | +-----+ 503 | |----------|............PW1.............|----------| | 504 | CE1 | | | | | | | | CE2 | 505 | |----------|............PW2.............|----------| | 506 +-----+ | | |==================| | | +-----+ 507 Customer^ +----+ +----+ | ^Customer 508 Edge 1 | Provider Edge 1 Provider Edge 2 | Edge 1 509 |<-------------- Emulated Service ---------------->| 511 Figure 1: PWE3 Network Reference Model 513 Any bits or packets presented at the PW End Service (PWES) are 514 encapsulated in a PW-PDU and carried across the underlying network. 515 The PEs perform the encapsulation, decapsulation, order management, 516 timing and any other functions required by the service. In some 517 cases the PWES can be treated as a virtual interfaces into a further 518 processing (like switching or bridging) of the original service 519 before the physical connection to the CE. Examples include Ethernet 520 bridging, SONET cross-connect, translation of locally-significant 521 identifiers such as VCI/VPI, etc. to other service type, etc. The 522 underlying PSN is not involved in any of these service-specific 523 operations. 525 3.2. Maintenance Reference Model 527 Figure 2 below shows the maintenance reference model for PWs. 529 |<------- CE (end-to-end) Signaling ------>| 530 | |<---- PW/PE Maintenance ----->| | 531 | | |<-- PSN Tunnel -->| | | 532 | | | Signaling | | | 533 | V V (out of scope) V V | 534 v +-----+ +-----+ v 535 +-----+ | PE1 |==================| PE2 | +-----+ 536 | |-----|.............PW1..............|-----| | 537 | CE1 | | | | | | CE2 | 538 | |-----|.............PW2..............|-----| | 539 +-----+ | |==================| | +-----+ 540 +-----+ +-----+ 541 Customer Provider Provider Customer 542 Edge 1 Edge 1 Edge 2 Edge 2 544 Figure 2: PWE3 Maintenance Reference Model 545 - The CE (end-to-end) signaling is between the CEs. This signaling 546 includes Frame Relay PVC status signaling, ATM SVC signaling, etc. 548 - The PW/PE Maintenance is used between the PEs to set up, maintain 549 and tear down PWs, including any required coordination of 550 parameters between the two ends. 552 - The PSN Tunnel signaling controls the underlying PSN. An example 553 would be LDP in MPLS for maintaining LSPs. This type of signaling 554 is not within the scope of PWE3. 556 3.3. Maintenance Architecture 558 563 3.3.1. PW Setup 565 How are PWs set up? 567 3.3.2. PW Integrity 569 How do we ensure the sanity or connectivity of the PW over the PSN? 571 3.3.3. Service Maintenance 573 How does CE maintenance behavior e.g. FR LMI, ATM AIS/RDI, etc. 574 affect the PW? 576 3.4. Protocol Stack Reference Model 578 Figure 3 below shows the protocol stack reference model for PWs. 580 +----------------+ +----------------+ 581 |Emulated Service| Emulated Service |Emulated Service| 582 |(TDM, ATM, etc).|<===========================>|(TDM, ATM, etc.)| 583 +----------------+ Pseudo Wire +----------------+ 584 | Encapsulation |<===========================>| Encapsulation | 585 +----------------+ PSN Tunnel +----------------+ 586 | IP/MPLS |<===========================>| IP/MPLS | 587 +----------------+ +----------------+ 588 | Physical | | Physical | 589 +-------+--------+ _____________ +--------+-------+ 590 | / \ | 591 +===============/ PSN \===============+ 592 \ / 593 \_____________/ 595 Figure 3: PWE3 Protocol Stack Reference Model 596 The PW provides the CE with what appears to be a connection to its 597 peer at the far end. Bits or PDUs from the CE are passed through an 598 encapsulation layer. 600 3.5. Logical Protocol Layering Model 602 3.5.1. Protocol Layers 604 The logical protocol-layering model needed to support a PW is shown 605 in Figure 4 below. 607 +---------------------------+ 608 | Payload | 609 +---------------------------+ 610 | Encapsulation Layer | 611 +---------------------------+ 612 | Multiplexing Layer | 613 +---------------------------+ 614 | PSN Header | 615 +---------------------------+ 616 | MAC/Datalink | 617 +---------------------------+ 618 | Physical | 619 +---------------------------+ 621 Figure 4: Logical Protocol Layering Model 623 The logical protocol-layering model shown in Figure 4 above minimizes 624 the differences between the PWs operating over different PSN types. 626 The payload is transported over the Encapsulation Layer that carries 627 any information that is not available in the payload itself and which 628 is needed by the CE Bound interface to send the reconstructed service 629 to the CE. If needed, this layer also provides support for real-time 630 processing, sequencing and indication of length. 632 The Multiplexing Layer provides the ability to deliver multiple PWs 633 over a single PSN tunnel. 635 The PSN header, MAC/datalink and physical layer definitions are 636 outside the scope of this framework. 638 3.5.2. Instantiation of the Protocol Layers 640 The instantiation of the logical protocol-layering model of Figure 4 641 is shown in Figure 5 below. 643 Where possible, the components shown below use existing IETF 644 standards and common work in progress. Otherwise, the goal was to 645 call for the design of components that have the wider application 646 within the IETF. 648 +=========================================+ - - - - - - - - - - 649 | Payload (circuit/cell/packet) | Payload 650 +=========================================+ - - - - - - - - - - 651 | Encapsulation-specific information | 652 | Sequencing (optional) | Encapsulation 653 | Length (payload/PSN-specific) | Layer 654 | Timing Information (payload-specific) | 655 +============+============================+ - - - - - - - - - - 656 | L2TPv3 | MPLS shim | Multiplexing Layer 657 +------------+-------+--------------------+ - - - - - - - - - - 658 | IPv4/v6 | MPLS | PSN Header 659 +====================+====================+ - - - - - - - - - - 660 | MAC/Data-link | 661 +=========================================+ 662 | Physical | 663 +=========================================+ 665 Figure 5: Instantiated Protocol Layering 667 3.5.2.1. Payload 669 The payload is generically classified into three types: circuit, cell 670 and packet. Within these generic types there will be specific service 671 types. For example, the generic packet type includes Frame Relay and 672 Ethernet. The design of the encapsulation layer, and the choice 673 between transporting the payload in a native or intermediate format, 674 will be defined in the service-specific EEMD and/or AS. 676 3.5.2.1.1. Circuit Payload 678 A circuit payload is a sampled set of bits relayed across the PW. 679 This service will need sequencing and real-time support. 681 3.5.2.1.2. Cell Payload 683 A cell payload is one, or more, ATM cells relayed across the PW. This 684 service will need sequence number support, and may also need 685 real-time support. The payload may consist of a single cell or a 686 cluster of cells. The cells to be incorporated in the payload may be 687 selected by filtering on VCI/VPI. In the case of a trunked interface 688 the payload may be considered complete on the expiry of a timer or 689 when a fixed number of cells have been received or both. 691 3.5.2.1.3. Packet Payload 693 A packet payload would normally be relayed across the PW as a single 694 unit. A packet payload may need sequencing or sequencing and 695 real-time support. A packet payload may additionally require 696 fragmentation 697 3.5.2.2. Sequencing 699 Support for sequencing depends on the payload type, and may be 700 omitted if not needed. For example, Frame Relay always requires the 701 preservation of packet order. However, where the Frame Relay service 702 is only being used to carry IP, it may be desirable to relax that 703 constraint in return for reduced per-packet processing cost. 705 [RTP] or encapsulation-specific sequence numbers may be used for 706 sequencing. 708 3.5.2.3. Timing 710 A suitable real-time protocol is RTP [RTP]. This is an extensible 711 protocol designed to be extended to carry new payload types over a 712 transport layer running over an IP network. It includes a control 713 protocol for managing the timing service. RTP is not currently 714 defined for operation over L2TP. A short document describing the 715 correct method of multiplexing the RTP control and data over LT2Pv3 716 is required. 718 3.5.2.4. Multiplexing Layer 720 Suitable protocols for use as a multiplexing layer are L2TPv3 [LAU] 721 and MPLS [MPLS]. 723 - The updated definition of L2TP in [LAU] is specified to operate 724 directly over a PSN, and in the limiting case the L2TP data 725 encapsulation reduces to a four-octet opaque data field. L2TPv3 is 726 specified for operation in both manually configured and negotiated 727 mode. The associated control protocol is extensible and may be 728 used to signal PW-specific configuration or run-time information. 730 - MPLS may also be used in the multiplexing layer. In this case, an 731 MPLS tag is used as a "shim" to identify the particular PW of 732 interest. 734 3.5.2.5. PSN Layer 736 The three PSN types within the scope of the IETF are IPv4, IPv6 and 737 MPLS. IPv4 and IPv6 both provide the necessary switching, length and 738 fragmentation services needed to support all IETF specified transport 739 protocols. L2TPv3 is specified to run directly over IPv4 and IPv6. 740 When the PSN is IPv4 or IPv6 no PSN convergence layer is needed. 742 MPLS provides switching service, but no length or fragmentation 743 service. When MPLS is used as the PSN, the encapsulation must provide 744 length and fragmentation services, if needed. 746 3.6. Architecture Assumptions 748 1) The current design is focused on a point-to-point and same-to-same 749 service interface at both end of the PW. Only network 750 interworking will be performed at the edge or the PW. Support for 751 service interworking is out of scope. 753 2) The initial design of PWE3 is focused on a single homogeneous 754 administrative PWD (e.g. PW over MPLS or PW over IP etc. ONLY). 755 Support for interworking between different PW types is for further 756 study, as is the support of inter-domain PWs. 758 3) The design of PW will not perfectly emulate the characteristics of 759 the native service. It will be dependent on both the emulated 760 service, as well as on the network implementation. An EEMD and AS 761 shall be created for each service to describe the degree of 762 faithfulness of a PW to the native service. 764 4) Only the permanent emulated circuit type (e.g. PVC/PVP) is 765 considered initially. Support for the switched emulated circuit 766 type (e.g. SVC/SVP) is be for further study. 768 5) The creation and placement of the PSN tunnel to support the PW is 769 not within the scope. 771 6) The current PW encapsulation approach considerations are focused 772 on IPv4, IPv6 and MPLS. Support for other encapsulation 773 approaches is for further study. 775 7) Current PW service applications are focused on Ethernet (i.e. 776 Ethernet II (DIX), 802.3 "raw", Ethernet 802.2, Ethernet SNAP, 777 802.3ac VLAN, 802.1Q), Frame Relay, ATM and TDM (e.g. DS1, DS3, 778 E1, SONET/SDH etc.). 780 8) Within the single administrative PWD, the design of the PW assumes 781 the inheritance of the security mechanism that has been applied to 782 the emulated services. The PW also inherits any security features 783 from the PSN e.g. IPsec for an IP PSN. No PW-specific security 784 mechanism will be specified. 786 4. Design Considerations 788 4.1. PW-PDU Validation 790 It is a common practice to use a checksum, CRC or FCS to assure 791 end-to-end integrity of frames. The PW service-specific mechanisms 792 must define whether the packet's checksum shall be preserved across 793 the PWD or be removed at the ingress PE and then be re-calculated at 794 the egress PE. The former approach saves work, while the later saves 795 bandwidth. 797 For protocols like ATM and Frame Relay, the checksum is only 798 applicable to a single link. This is because the circuit identifiers 799 (e.g. Frame Relay DLCI or ATM VPI/VCI) have only local significance 800 and are changed on each hop or span. If the circuit identifier (and 801 thus checksum) is going to change as a part of the PW emulation, it 802 would be more efficient to strip and re-calculate the checksum. 804 Other PDU headers (e.g. UDP in IP) do not change during transit. It 805 would make sense to preserve these types of checksums. 807 The EEMD for each protocol must describe the validation scheme to be 808 used. 810 4.2. PW-PDU Sequencing 812 One major consideration of PW design is how to ensure in-sequence 813 delivery of packets, if needed. The design of the PW for each 814 protocol must consider the support of the PSN for in-order delivery 815 as well as the requirements of the particular application. For 816 example, IP is connectionless and does not guarantee in-order 817 delivery. When using IP, a PW sequence number may be needed for some 818 applications (such as TDM). 820 4.3. Session Multiplexing 822 One way to facilitate scaling is to increase the number of PWs per 823 underlying tunnel. There are two ways to achieve this: 825 - For a service like Relay or ATM, all of the VCs on a given port 826 could be lumped together. VCs would not be distinguishable within 827 the PWD. 829 - Service SDUs could be distinguished within a PW-PDU by port, 830 channel or VC identifiers. This approach would allow for switching 831 or grooming in the PWD. 833 4.4. Security 835 Each EEMD must specify a means to protect the control of the PWE and 836 the PE/PW signaling. The security-related protection of the 837 encapsulated content of the PW is outside of scope. 839 4.5. Encapsulation Control 841 4.5.1. Scalability 843 Different service types may be required between CEs. Support of 844 multiple services implies that a range of PWD label spaces may be 845 needed. If the PWD spans a PSN supporting traffic engineering, then 846 the ability to supporting label stacking would be desirable. 848 4.5.2. Service Integration 850 It may be desirable to design a PW to transport a variety of services 851 which have different transport characteristics. To achieve this 852 integration it may be useful to allow the service requirements to be 853 mapped to the tunneling label in such a way that the PWD can apply 854 the appropriate service and transport management to the PW. 856 4.6. Statistics 858 The PE can tabulate statistics that help monitor the state of the 859 network, and to help with measurement of SLAs. Typical counters 860 include: 862 - Counts of PW-PDUs sent and received, with and without errors. 864 - Counts of PW-PDUs lost (TDM only). 866 - Counts of service PDUs sent and received, with and without errors 867 (non-TDM). 869 - Service-specific interface counts. 871 These counters would be contained in a PW-specific MIB, and they 872 should not replicate existing MIB counters. 874 4.7. Traceroute 876 Tracing functionality is desirable for emulated services, because it 877 allows verification and remediation of the operation and 878 configuration of the forwarding plane. [BONICA] describes the 879 requirements for a generic route tracing application. Applicability 880 of these requirements to PWE3 is an interesting problem, as many of 881 the emulated services have no equivalent function. In general, there 882 is not a way to trace the forwarding plane of an TDM or Frame Relay 883 PVC. ATM does provide an option in the loopback OAM cell to return 884 each intermediate hop (see [I.610]). 886 There needs to be a mechanism through which upper layers can ask 887 emulated services to reveal their internal forwarding details. A 888 common mechanism for all emulated services over a particular PSN may 889 be possible. For example, if MPLS is the PSN, the path for a VC LSP 890 could be revealed via the signaling from the underlying TE tunnel 891 LSP, or perhaps via the proposed MPLS OAM. However, when we are 892 trying to trace the entire emulated service, starting from the CE 893 (e.g. an ATM VCC), then a uniform approach probably will not work and 894 different approaches would be required for different emulated 895 services. 897 4.8. Congestion Considerations 899 The PSN carrying the PW may be subject to congestion. The congestion 900 characteristics will vary with the PSN type, the network architecture 901 and configuration, and the loading of the PSN. 903 Each PW EEMD and/or AS will have to specify whether it needs an 904 appropriate mechanism for operating in the presence of this 905 congestion, including methods of mapping between its native 906 congestion reporting and avoidance mechanisms, and those provided by 907 the PW. 909 4.9. PW SNMP MIB Architecture 911 This section describes the general architecture for SNMP MIBs used to 912 manage PW services and the underlying PSN. The intent here is to 913 provides a clear picture of how all of the pertinent MIBs fit 914 together to form a cohesive management framework for deploying PWE3 915 services. 917 4.9.1. MIB Layering 919 The SNMP MIBs created for PWE3 should fit the architecture shown in 920 Figure 6. 922 +-----------+ +-----------+ +-----------+ 923 Service | CEM | | Ethernet | | ATM | 924 Layer |Service MIB| |Service MIB| ... |Service MIB| 925 +-----------+ +-----------+ +-----------+ 926 \ | / 927 \ | / 928 - - - - - - - - - - - - \ - - - | - - - - / - - - - - - - 929 \ | / 930 +-------------------------------------------+ 931 Generic PW | Generic PW MIBs | 932 Layer +-------------------------------------------+ 933 / | \ 934 - - - - - - - - - - - - / - - - | - - - - \ - - - - - - - 935 / | \ 936 / | \ 937 +-----------+ +-----------+ +-----------+ 938 PSN VC |GRE VC MIB | |L2TP VC MIB| |MPLS VC MIB| 939 Layer +-----------+ +-----------+ +-----------+ 940 | | | 941 - - - - - - - - - | - - - - - - | - - - - - - - - | - - - 942 | | | 943 +-----------+ +-----------+ +-----------+ 944 PSN |GRE MIB(s) | |L2TP MIB(s)| |MPLS MIB(s)| 945 Layer +-----------+ +-----------+ +-----------+ 947 Figure 6: Relationship of SNMP MIBs 948 Figure 7 shows an example for a TDM PW carried over MPLS. 950 +-----------------+ 951 | SONET MIB | RFC2558 952 +-----------------+ 953 | 954 +-----------------+ 955 Service |SONET Service MIB| pw-cem-mib 956 Layer +-----------------+ 957 - - - - - - - - - - | - - - - - - - - - - - - - - - 958 +-----------------+ 959 Generic PW | Generic PW MIBS | pw-tc-mib 960 Layer +-----------------+ pw-mib 961 - - - - - - - - - - | - - - - - - - - - - - - - - - 962 +-----------------+ 963 PSN VC | MPLS VC MIBS | pw-mpls-mib 964 Layer +-----------------+ 965 - - - - - - - - - - | - - - - - - - - - - - - - - - 966 +-----------------+ 967 PSN | MPLS MIBs | mpls-te-mib 968 Layer +-----------------+ mpls-lsr-mib 970 Figure 7: Service-specific Example for MIBs 972 Note that there is a separate MIB for each emulated service as well 973 as one for each underlying PSN. These MIBs may be used in various 974 combinations as needed. 976 4.9.2. Service Layer MIBs 978 The first layer is referred to as the Service Layer. It contains 979 MIBs for PWE3 services such as Ethernet, ATM, circuits and Frame 980 Relay. This layer contains those corresponding MIBs used to mate or 981 adapt those emulated services to the underlying services. This 982 working group should not produce any MIBs for managing the general 983 service; rather, it should produce just those MIBs that are used to 984 interface or adapt the emulated service onto the PWE3 management 985 framework. For example, the standard SONET MIB [SONETMIB] is 986 designed and maintained by another working group. Also, the SONET MIB 987 is designed to manage the native service without PW emulation. Since 988 the PWE3 working group is chartered to produce the corresponding 989 adaptation MIB, in this case, it would produce the PW-CEM-MIB 990 [PWMPLSMIB] that would be used to adapt SONET services to the 991 underlying PSN that carries the PWE3 service. 993 4.9.3. Generic PW MIBs 995 The second layer is referred to as the Generic PW Layer. This layer 996 is composed of two MIBs: the PWE-TC-MIB [PWTCMIB] and the PWE-MIB 997 [PWMIB]. These MIBs are responsible for providing general PWE3 998 counters and service models used for monitoring and configuration of 999 PWE3 services over any supported PSN service. That is, this MIB 1000 provides a general model of PWE3 abstraction for management purposes. 1001 This MIB is used to interconnect the Service Layer MIBs to the PSN VC 1002 Layer MIBs. The latter will be described in the next section. This 1003 layer also provides the PW-TC-MIB [PWTCMIB]. This MIB contains common 1004 SMI textual conventions [SMIv2] that may be used by any PW MIB. 1006 4.9.4. PSN VC Layer MIBs 1008 The third layer in the PWE3 management architecture is referred to as 1009 the PSN VC layer. This layer is comprised of MIBs that are 1010 specifically designed to interface general PWE3 services (VCs) onto 1011 those underlying PSN services. In general this means that the MIB 1012 provides a means with which an operator can map the PW service onto 1013 the native PSN service. For example, in the case of MPLS, it is 1014 required that the general VC service be layered onto MPLS LSPs or 1015 Traffic Engineered (TE) Tunnels [MPLS]. In this case, the PW-MPLS-MIB 1016 [PWMPLSMIB] was created to adapt the general PWE3 circuit services 1017 onto MPLS. Like the Service Layer described above the PWE3 working 1018 group should produce these MIBs. 1020 4.9.5. PSN Layer MIBs 1022 The fourth and final layer in the PWE3 management architecture is 1023 referred to as the PSN layer. This layer is comprised of those MIBs 1024 that control the PSN service-specific services. For example, in the 1025 case of the MPLS [MPLS] PSN service, the MPLS-LSR-MIB [LSRMIB] and 1026 the MPLS-TE-MIB [TEMIB] are used to interface the general PWE3 VC 1027 services onto native MPLS LSPs and/or TE tunnels to carry the 1028 emulated services. In addition, the MPLS-LDP-MIB [LDPMIB] may be 1029 used to reveal the MPLS labels that are distributed over the MPLS PSN 1030 in order to maintain the PW service. The MIBs in this layer are 1031 produced by other working groups that design and specify the native 1032 PSN services. These MIBs should contain the appropriate mechanisms 1033 for monitoring and configuring the PSN service such that the emulated 1034 PWE3 service will function correctly. 1036 5. Acknowledgments 1038 This document was created by the PWE3 Framework design team. 1039 Valuable input was also provided by John Rutemiller, David Zelig, 1040 Durai Chinnaiah, Jayakumar Jayakumar, Ron Bonica, Ghassem Koleyni, 1041 and Eric Rosen. 1043 6. References 1045 [L2TP] W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall, G. 1046 Zorn, B. Palter, "Layer Two Tunneling Protocol (L2TP)", RFC 1047 2661, August 1999. 1049 [RTP] H. Schulzrinne et al, "RTP: A Transport Protocol for 1050 Real-Time Applications", RFC1889, January 1996. 1052 [MPLS] E. Rosen, "Multiprotocol Label Switching Architecture", 1053 RFC3031, January 2001. 1055 [IP] DARPA, "Internet Protocol", RFC791, September 1981. 1057 [CONGEST] S. Floyd, "Congestion Control Principles", RFC2914, 1058 September 2000. 1060 [SONETMIB] K. Tesink, "Definitions of Managed Objects for the SONET/SDH 1061 Interface Type", RFC2558, March 1999. 1063 [SMIv2] Case et al, "Structure of Management Information for Version 1064 2 of the Simple Network Management Protocol (SNMPv2)", 1065 RFC1902, January 1996. 1067 [MALIS] Malis et al, "SONET/SDH Circuit Emulation over Packet (CEP)" 1068 (draft-malis-pwe3-sonet-01.txt), work in progress, November 1069 2001. 1071 [XIAO] Xiao et al, "Requirements for Pseudo Wire Emulation 1072 Edge-to-Edge (PWE3)" (draft-pwe3-requirements-02.txt), work 1073 in progress, November 2001. 1075 [BONICA] Bonica et al, "Tracing Requirements for Generic Tunnels" 1076 (draft-bonica-tunneltrace-02.txt), work in progress, 1077 November 2001. 1079 [LAU] J Lau et al, Layer Two Tunneling Protocol "L2TP", 1080 (draft-ietf-l2tpext-l2tp-base-02.txt) work in progress, 1081 March 2002. 1083 [PWMIB] Zelig et al, "Pseudo Wire (PW) Management Information Base 1084 Using SMIv2", (draft-zelig-pw-mib-02.txt), work in progress, 1085 February 2002. 1087 [PWTCMIB] Nadeau et al, "Definitions for Textual Conventions and 1088 OBJECT-IDENTITIES for Pseudo-Wires Management" 1089 (draft-nadeau-pw-tc-mib-02.txt), work in progress, February 1090 2002. 1092 [PWMPLSMIB] Danenberg et al, "SONET/SDH Circuit Emulation Service Over 1093 MPLS (CEM) Management Information Base Using SMIv2", 1094 (draft-danenberg-pw-cem-mib-01.txt), work in progress, 1095 November 2001. 1097 [LSRMIB] Srinivasan et al, "MPLS Label Switch Router Management 1098 Information Base Using SMIv2", 1099 draft-ietf-mpls-lsr-mib-08.txt, work in progress, January 1100 2002. 1102 [TEMIB] Srinivasan et al, "Traffic Engineering Management 1103 Information Base Using SMIv2", 1104 , work in progress, January 1105 2002. 1107 [LDP-MIB] Cucchiara, J., Sjostrand, H., and Luciani, J., "Definitions 1108 of Managed Objects for the Multiprotocol Label Switching, 1109 Label Distribution Protocol (LDP)", 1110 , work in progress, August 1111 2001. 1113 [ATMCES] ATM Forum, "Circuit Emulation Service Interoperability 1114 Specification Version 2.0" (af-vtoa-0078-000), January 1997. 1116 [FRF.5] O'Leary et al, "Frame Relay/ATM PVC Network Interworking 1117 Implementation Agreement", Frame Relay Forum FRF.5, December 1118 20, 1994. ITU Recommendation Q.933, Annex A, Geneva, 1995. 1120 [I.363.1] ITU, "B-ISDN ATM Adaptation Layer specification: Type 1 1121 AAL", Recommendation I.363.1, August, 1996. 1123 [I.610] ITU, "B-ISDN Operation and Maintenance Principles and 1124 Functions", ITU Recommendation I.610, February, 1999. 1126 [802.3] IEEE, "ISO/IEC 8802-3: 2000 (E), Information 1127 technology--Telecommunications and information exchange 1128 between systems --Local and metropolitan area networks 1129 --Specific requirements --Part 3: Carrier Sense Multiple 1130 Access with Collision Detection (CSMA/CD) Access Method and 1131 Physical Layer Specifications", 2000. 1133 7. Security Considerations 1135 It may be desirable to define methods for ensuring security during 1136 exchange of encapsulation control information at an administrative 1137 boundary of the PSN. 1139 8. IANA Considerations 1141 There are no IANA considerations for this document. 1143 9. Authors' Addresses 1145 Prayson Pate XiPeng Xiao 1146 Overture Networks, Inc. Redback Networks 1147 P. O. Box 14864 300 Holger Way 1148 RTP, NC, USA 27709 San Jose, CA 95134 1149 prayson.pate@overturenetworks.com xipeng@redback.com 1151 Tricci So Craig White 1152 Caspian Networks Level 3 Communications, LLC. 1153 170 Baytech Dr. 1025 Eldorado Blvd. 1154 San Jose, CA 95134 Broomfield, CO, 80021 1155 tso@caspiannetworks.com Craig.White@Level3.com 1156 Kireeti Kompella Andrew G. Malis 1157 Juniper Networks, Inc. Vivace Networks, Inc. 1158 1194 N. Mathilda Ave. 2730 Orchard Parkway 1159 Sunnyvale, CA 94089 San Jose, CA 95134 1160 kireeti@juniper.net Andy.Malis@vivacenetworks.com 1162 Thomas K. Johnson Thomas D. Nadeau 1163 Litchfield Communications Cisco Systems, Inc. 1164 76 Westbury Park Rd. 250 Apollo Drive 1165 Watertown, CT 06795 Chelmsford, MA 01824 1166 tom_johnson@litchfieldcomm.com tnadeau@cisco.com 1168 Stewart Bryant 1169 Cisco Systems Ltd 1170 4, The Square 1171 Stockley Park 1172 Uxbridge UB11 1BL UK 1173 stbryant@cisco.com 1175 10. Full Copyright Section 1177 Copyright (C) The Internet Society (2002). All Rights Reserved. 1179 This document and translations of it may be copied and furnished to 1180 others, and derivative works that comment on or otherwise explain it 1181 or assist in its implementation may be prepared, copied, published 1182 and distributed, in whole or in part, without restriction of any 1183 kind, provided that the above copyright notice and this paragraph are 1184 included on all such copies and derivative works. However, this 1185 document itself may not be modified in any way, such as by removing 1186 the copyright notice or references to the Internet Society or other 1187 Internet organizations, except as needed for the purpose of 1188 developing Internet standards in which case the procedures for 1189 copyrights defined in the Internet Standards process must be 1190 followed, or as required to translate it into languages other than 1191 English. 1193 The limited permissions granted above are perpetual and will not be 1194 revoked by the Internet Society or its successors or assigns. 1196 This document and the information contained herein is provided on an 1197 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1198 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1199 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1200 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1201 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.