idnits 2.17.00 (12 Aug 2021) /tmp/idnits43012/draft-pate-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: ---------------------------------------------------------------------------- ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 497 has weird spacing: '...itching or br...' == 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 section? 'ATMCES' on line 2113 looks like a reference -- Missing reference section? 'ANAVI' on line 2088 looks like a reference -- Missing reference section? 'MARTINI' on line 2099 looks like a reference -- Missing reference section? 'GR253' on line 2201 looks like a reference -- Missing reference section? 'MALIS' on line 2091 looks like a reference -- Missing reference section? 'RTP' on line 2075 looks like a reference -- Missing reference section? 'G.811' on line 2160 looks like a reference -- Missing reference section? 'G.823' on line 2163 looks like a reference -- Missing reference section? 'G.824' on line 2167 looks like a reference -- Missing reference section? 'NTP' on line 2078 looks like a reference -- Missing reference section? 'ILMI' on line 2119 looks like a reference -- Missing reference section? 'BONICA' on line 2103 looks like a reference -- Missing reference section? 'RFC2914' on line 1824 looks like a reference -- Missing reference section? 'IP' on line 2084 looks like a reference -- Missing reference section? 'L2TP' on line 2071 looks like a reference -- Missing reference section? 'MPLS' on line 2081 looks like a reference -- Missing reference section? 'XIAO' on line 2095 looks like a reference -- Missing reference section? 'CALLON' on line 2107 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Prayson Pate 2 Document: draft-pate-pwe3-framework-01.txt Overture Networks 3 Expires: January 13, 2002 XiPeng Xiao 4 Photuris Inc. 5 Tricci So 6 Caspian Networks 7 Craig White Kireeti Kompella 8 Level 3 Communications, LLC. Juniper Networks, Inc. 9 Andrew G. Malis Thomas K. Johnson 10 Vivace Networks Litchfield Communications 12 Framework for 13 Pseudo Wire Emulation Edge-to-Edge (PWE3) 14 draft-pate-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 Wires Emulation Edge- 38 to-Edge (PWE3). It discusses the emulation of circuits (such as T1, 39 E1, T3, E3 and SONET/SDH) and services (such as ATM and Frame Relay) 40 over packet switched networks (PSNs) using IP, L2TP or MPLS. It 41 presents an architectural framework for pseudo wires (PWs), defines 42 terminology, specifies the various protocol elements and their 43 functions, overviews some of the services that will be supported and 44 discusses how PWs fit into the broader context of protocols. 46 Copyright Notice 48 Copyright (C) The Internet Society (2001). All Rights Reserved. 50 Table of Contents 51 1 Introduction ................................................. 3 52 2 Background and Motivation .................................... 5 53 3 Architecture of Pseudo Wires ................................. 8 54 4 Layer 1 (Circuit) Applications ............................... 15 55 5 Layer 2 (Packet/Cell) Applications ........................... 25 56 6 PW Maintenance ............................................... 36 57 7 Packet Switched Networks ..................................... 40 58 8 Acknowledgments .............................................. 43 59 9 References ................................................... 43 60 10 Security Considerations ..................................... 45 61 11 Authors' Addresses .......................................... 46 62 12 Full Copyright Section ...................................... 47 63 1. Introduction 65 This document describes a framework for Pseudo Wires Emulation Edge- 66 to-Edge (PWE3). It discusses the emulation of circuits (such as T1, 67 E1, T3, E3 and SONET/SDH) and services (such as ATM and Frame Relay) 68 over packet switched networks (PSNs) using IP, L2TP or MPLS. It 69 presents an architectural framework for pseudo wires (PWs), defines 70 terminology, specifies the various protocol elements and their 71 functions, overviews the services supported and discusses how PWs fit 72 into the broader context of protocols. 74 1.1. What Are Pseudo Wires? 76 1.1.1. Definition 78 PWE3 is a mechanism that emulates the essential attributes of a 79 service (such as a T1 leased line or Frame Relay) over a PSN. The 80 required functions of PWs include encapsulating service-specific bit- 81 streams or PDUs arriving at an ingress port, and carrying them across 82 a path or tunnel, managing their timing and order, and any other 83 operations required to emulate the behavior and characteristics of 84 the service as faithfully as possible. 86 From the customer perspective, the PW is perceived as an unshared 87 link or circuit of the chosen service. However, there may be 88 deficiencies that impede some applications from being carried on a 89 PW. These limitations should be fully described in the appropriate 90 service-specific Applicability Statements (ASes). 92 1.1.2. Functions 94 PWs provide the following functions in order to emulate the behavior 95 and characteristics of the desired service. 97 - Encapsulation of service-specific PDUs or circuit data arriving at 98 an ingress port (logical or physical). 100 - Carrying the encapsulated data across a tunnel. 102 - Managing the signaling, timing, order or other aspects of the 103 service at the boundaries of the PW. 105 - Service-specific status signaling and alarm management. 107 ASes for each service will describe any shortfalls of the emulation's 108 faithfulness. 110 1.2. Goals of This Document 112 - Description of the motivation for creating PWs, and some background 113 on how they may be deployed. 115 - Description of an architecture and terminology for PWs. 117 - Description of the relevant services that will be supported by PWs, 118 including any relevant service-specific considerations. 120 - Description of methods to ensure in-order final PDU delivery, 122 - Description of methods to perform clock recovery, as needed or 123 appropriate. 125 - Description of methods to perform edge-to-edge/inband signaling 126 functions across the PSN, as needed or appropriate. 128 - Description of the statistics and other network management 129 information needed for tunnel operation and management. 131 - Description of the security mechanisms to be used to protect the 132 control of the PW technology. The protection of the encapsulated 133 content (e.g., payload encryption) of the PW is outside of scope. 135 - Description of a mechanism to exchange encapsulation control 136 information at an administrative boundary of the PSN, including 137 security methods. 139 - Whenever possible, relevant requirements from existing IETF 140 documents and other sources will be incorporated by reference. 142 1.3. Non-Goals 144 The following are out of scope: 146 - The protection of the encapsulated content of the PW. 148 - Any multicast service not native to the emulated medium. Thus, 149 Ethernet transmission to a "multicast" IEEE-48 address is in scope, 150 while multicast services like MARS that are implemented on top of 151 the medium are out of scope. 153 - Methods to signal the underlying PSN. 155 2. Background and Motivation 157 Many of today's service providers are struggling with the dilemma of 158 moving to an optical network based on IP and/or MPLS. How do they 159 realize the capital and operational benefits of a new packet-based 160 optical infrastructure, while leveraging the existing base of SONET 161 (Synchronous Optical Network) gear, and while also protecting the 162 large revenue stream associated with this equipment? How do they 163 move from mature Frame Relay or ATM networks, while still being able 164 to provide these lucrative services? One possibility is the 165 emulation of circuits or services via PWs. Circuit emulation over 166 ATM and interworking of Frame Relay and ATM have already been 167 standardized. Emulation allows existing circuits and/or services to 168 be carried across the new infrastructure, and thus enables the 169 interworking of disparate networks. [ATMCES] provides some insight 170 into the requirements for such a service: 172 There is a user demand for carrying certain types of 173 constant bit rate (CBR) or "circuit" traffic over 174 Asynchronous Transfer Mode (ATM) networks. As ATM is 175 essentially a packet- rather than circuit-oriented 176 transmission technology, it must emulate circuit 177 characteristics in order to provide good support for CBR 178 traffic. 180 A critical attribute of a Circuit Emulation Service (CES) 181 is that the performance realized over ATM should be 182 comparable to that experienced with the current PDH/SDH 183 technology. 185 Section 4 of [ANAVI] gives more background on why such emulation is 186 desirable: 188 The simplicity of TDMoIP translates into initial 189 expenditure and operational cost benefits. In addition, due 190 to its transparency TDMoIP can support mixed voice, data 191 and video services. It is transparent to both protocols and 192 signaling, irrespective of whether they are standards based 193 or proprietary with full timing support and the capability 194 of maintaining the integrity of framed and unframed DS1 195 formats. 197 2.1. Current Network Architecture 199 2.1.1. Multiple Networks 201 For any given service provider delivering multiple services, the 202 current "network" usually consists of parallel or "overlay" networks. 203 Each of these networks implements a specific service, such as voice, 204 Frame Relay, Internet access, etc. This is quite expensive, both in 205 terms of capital expense as well as in operational costs. 206 Furthermore, the presence of multiple networks complicates planning. 208 Service providers wind up asking themselves these questions: 210 - Which of my networks do I build out? 212 - How many fibers do I need for each network? 214 - How do I efficiently manage multiple networks? 216 2.1.2. Convergence Today 218 There are some examples of convergence in today's network: 220 - Frame Relay is frequently carried over ATM networks using [FRF.5] 221 interworking. 223 - T1, E1 and T3 circuits are sometimes carried over ATM networks 224 using [ATMCES]. 226 - Voice is carried over ATM (using AAL2), Frame Relay (using FRF.11 227 VoFR), IP (using VoIP) and MPLS (using VoMPLS) networks. 229 Deployment of these examples range from limited (ATM CES) to fairly 230 common (FRF.5 interworking) to rapidly growing (VoIP). 232 2.2. The Emerging Converged Network 234 Many service providers are finding that the new IP-based and MPLS- 235 based switching systems are much less costly to acquire, deploy and 236 maintain than the systems that they replace. The new systems take 237 advantage of advances in technology in these ways: 239 - The newer systems leverage mass production of ASICs and optical 240 interfaces to reduce capital expense. 242 - The bulk of the traffic in the network today originates from packet 243 sources. Packet switches can economically switch and deliver this 244 traffic natively. 246 - Variable-length switches have lower system costs than ATM due to 247 simpler switching mechanisms as well as elimination of segmentation 248 and reassembly (SAR) at the edges of the network. 250 - Deployment of services is simpler due to the connectionless nature 251 of IP services or the rapid provisioning of MPLS applications. 253 2.3. Transition to a IP-Optimized Converged Network 255 The greatest assets for many service providers are the physical 256 communications links that they own. The time and costs associated 257 with acquiring the necessary rights of way, getting the required 258 governmental approvals, and physically installing the cabling over a 259 variety of terrains and obstacles represents a significant asset that 260 is difficult to replace. Their greatest on-going costs are the 261 operational expenses associated with maintaining and operating their 262 networks. In order to maximize the return on their assets and 263 minimize their operating costs, service providers often look to 264 consolidate the delivery of multiple service types onto a single 265 networking technology. 267 The first generation converged network is based on TDM (time-division 268 multiplexing) technology. Voice, video, and data traffic has been 269 carried successfully across TDM/DACS-based networks for decades. TDM 270 technology has some significant drawbacks as a converged networking 271 technology. Operational costs for TDM networks remain relatively 272 high because the provisioning of end-to-end TDM circuits is typically 273 a tedious and labor-intensive task. In addition, TDM switching does 274 not make the best use of the communications links. This is because 275 fixed assignment of timeslots does not allow for the statistical 276 multiplexing of bursty data traffic (i.e. temporarily unused 277 bandwidth on one timeslot cannot be dynamically re-allocated to 278 another service). 280 The second generation of converged network is based on ATM 281 technology. Today many service providers convert voice, video, and 282 data traffic into fixed-length cells for carriage across ATM-based 283 networks. ATM improves upon TDM technology by providing the ability 284 to statistically multiplex different types of traffic onto 285 communications links. In addition, ATM SPVC technology is often used 286 to automatically provision end-to-end services, providing an 287 additional advantage over traditional TDM networks. However, ATM has 288 several significant drawbacks. One of the most frequently cited 289 problems with ATM is the so-called cell-tax, which refers to the 5 290 bytes out of 53 used as an ATM cell header. Another significant 291 problem with ATM is the AAL5 SAR, which becomes extremely difficult 292 to implement above 1 Gbps. There are also issues with the long-term 293 scalability of ATM, especially as a switching layer beneath IP. 295 As IP traffic takes up a larger and larger portion of the available 296 network bandwidth, it becomes increasingly useful to optimize public 297 networks for the Internet Protocol. However, many service providers 298 are confronting several obstacles in engineering IP-optimized 299 networks. Although Internet traffic is the fastest growing traffic 300 segment, it does not generate the highest revenue per bit. For 301 example, Frame Relay traffic currently generates a higher revenue per 302 bit than do native IP services. Private line TDM services still 303 generate even more revenue per bit than does Frame Relay. In 304 addition, there is a tremendous amount of legacy equipment deployed 305 within public networks that does not communicate using the Internet 306 Protocol. Service providers continue to utilize non-IP equipment to 307 deploy a variety of services, and see a need to interconnect this 308 legacy equipment over their IP-optimized core networks. 310 To maximize the return on their assets and minimize their operational 311 costs, many service providers are looking to consolidate the delivery 312 of multiple service offerings and traffic types onto a single IP- 313 optimized network. 315 In order to create this next-generation converged network, standard 316 methods must be developed to emulate existing telecommunications 317 formats such as Ethernet, Frame Relay, ATM, and TDM over IP-optimized 318 core networks. This document describes a framework accomplishing 319 this goal. 321 3. Architecture of Pseudo Wires 323 3.1. Terminology 325 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", 326 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 327 document are to be interpreted as described in RFC 2119. Below are 328 the definitions for the terms used throughout the document. 330 Packet Switched Network 331 A Packet Switched Network (PSN) is a network 332 using IP, MPLS or L2TP as the unit of 333 switching. 335 Pseudo Wire Emulation Edge to Edge 336 Pseudo Wire Emulation Edge to Edge (PWE3) is a 337 mechanism that emulates the essential 338 attributes of a service (such as a T1 leased 339 line or Frame Relay) over a PSN. 341 Customer Edge A Customer Edge (CE) is a device where one end 342 of an emulated service originates and 343 terminates. The CE is not aware that it is 344 using an emulated service rather than a "real" 345 service. 347 Provider Edge A Provider Edge (PE) is a device that provides 348 PWE3 to a CE. 350 Pseudo Wire A Pseudo Wire (PW) is a connection between two 351 PEs carried over a PSN. The PE provides the 352 adaptation between the CE and the PW. 354 PW End Service A Pseudo Wire End Service (PWES) is the 355 interface between a PE and a CE. This can be a 356 physical interface like a T1 or Ethernet, or a 357 virtual interface like a VC or VLAN. 359 Pseudo Wire PDU A Pseudo Wire PDU is a PDU sent on the PW that 360 contains all of the data and control 361 information necessary to provide the desired 362 service. 364 PSN Tunnel A PSN Tunnel is a tunnel inside which multiple 365 PWs can be nested so that they are transparent 366 to core network devices. 368 Pseudo Wire Domain A PW Domain (PWD) is a collection of instances 369 of PWs that are within the scope of a single 370 homogenous administrative domain (e.g. PW over 371 MPLS network or PW over IP network etc.). 373 Path-oriented PW A Path-oriented PW is a PW for which the 374 network devices of the underlying PSN must 375 maintain state information. 377 Non-path-oriented PW A Non-path-oriented PW is a PW for which the 378 network devices of the underlying PSN need not 379 maintain state information. 381 Interworking Interworking is used to express interactions 382 between networks, between end systems, or 383 between parts thereof, with the aim of 384 providing a functional entity capable of 385 supporting an end-to-end communication. The 386 interactions required to provide a functional 387 entity rely on functions and on the means to 388 select these functions. 390 Interworking Function An Interworking Function (IWF) is a functional 391 entity that facilitates interworking between 392 two dissimilar networks (e.g., ATM & MPLS, ATM 393 & L2TP, etc.). A PE performs the IWF function. 395 Service Interworking In Service Interworking, the IWF (Interworking 396 Function) between two dissimilar protocols 397 (e.g., ATM & MPLS, Frame Relay & ATM, ATM & IP, 398 ATM & L2TP, etc.) terminates the protocol used 399 in one network and translates (i.e. maps) its 400 Protocol Control Information (PCI) to the PCI 401 of the protocol used in other network for User, 402 Control and Management Plane functions to the 403 extent possible. In general, since not all 404 functions may be supported in one or other of 405 the networks, the translation of PCI may be 406 partial or non-existent. However, this should 407 not result in any loss of user data since the 408 payload is not affected by PCI conversion at 409 the service interworking IWF. 411 Network Interworking In Network Interworking, the PCI (Protocol 412 Control Information) of the protocol and the 413 payload information used in two similar 414 networks are transferred transparently by an 415 IWF of the PE across the PSN. Typically the 416 IWF of the PE encapsulates the information 417 which is transmitted by means of an adaptation 418 function and transfers it transparently to the 419 other network. 421 Applicability Statement 422 Each PW service will have an Applicability 423 Statement (AS) that describes the particulars 424 of PWs for that service, as well as the degree 425 of faithfulness to that service. 427 Outbound The traffic direction where information from a 428 CE is adapted to a PW, and PW-PDUs are sent 429 into the PSN. 431 Inbound The traffic direction where PW-PDUs are 432 received on a PW from the PSN, re-converted 433 back in the emulated service, and sent out to a 434 CE. 436 CE Signaling CE (end-to-end) Signaling refers to messages 437 sent and received by the CEs. It may be 438 desirable or even necessary for the PE to 439 participate in or monitor this signaling in 440 order to effectively emulate the service. 442 PE/PW Signaling PE/PW Signaling is signaling used by the PEs to 443 set up and tear down the PW. It may be coupled 444 with CE signaling in order to effectively 445 manage the PW. 447 PSN Tunnel Signaling PSN Tunnel Signaling is used to set up, 448 maintain and remove the underlying PSN tunnel. 449 An example would be LDP in MPLS for maintaining 450 LSPs. This type of signaling is not within the 451 scope of PWE3. 453 457 [MARTINI] This Draft 458 ---------------------------------------- 459 MPLS Network PSN (includes MPLS) 460 Tunnel LSP PSN Tunnel 461 VC LSP PW 462 Edge LSR, R1, R2 PE 464 Figure 1: Comparison of Terms 465 3.2. Reference Models 467 3.2.1. Network Reference Model 469 Figure 2 below shows the network reference model for PWs. 471 |<------- Pseudo Wire ------>| 472 | | 473 | |<-- PSN Tunnel -->| | 474 PW V V V V PW 475 End Service+----+ +----+ End Service 476 +-----+ | | PE1|==================| PE2| | +-----+ 477 | |----------|............PW1.............|----------| | 478 | CE1 | | | | | | | | CE2 | 479 | |----------|............PW2.............|----------| | 480 +-----+ | | |==================| | | +-----+ 481 ^ +----+ +----+ | ^ 482 | Provider Edge 1 Provider Edge 2 | 483 | | 484 |<-------------- Emulated Service ---------------->| 486 Customer Customer 487 Edge 1 Edge 2 489 Figure 2: PWE3 Network Reference Model 491 As shown, the PW provides an emulated service between the customer 492 edges (CEs). Any bits or packets presented at the PW End Service 493 (PWES) are encapsulated in a PW-PDU and carried across the underlying 494 network. The PEs perform the encapsulation, decapsulation, order 495 management, timing and any other functions required by the service. 496 In some cases the PWES can be treated as a virtual interfaces into a 497 further processing (like switching or bridging) of the original 498 service before the physical connection to the CE. Examples include 499 Ethernet bridging, SONET cross-connect, translation of locally- 500 significant identifiers such as VCI/VPI, etc. to other service type, 501 etc. 503 The underlying PSN is not involved in any of these service-specific 504 operations. 506 3.2.2. Signaling Reference Model 508 Figure 3 below shows the signaling reference model for PWs. 510 |<------- CE (end-to-end) Signaling ------>| 511 | | 512 | | 513 | |<----- PW/PE Signaling ------>| | 514 | | | | 515 | | |<-- PSN Tunnel -->| | | 516 | | | Signaling | | | 517 | V V V V | 518 v +-----+ +-----+ v 519 +-----+ | PE1 |==================| PE2 | +-----+ 520 | |-----|.............PW1..............|-----| | 521 | CE1 | | | | | | CE2 | 522 | |-----|.............PW2..............|-----| | 523 +-----+ | |==================| | +-----+ 524 ^ +-----+ +-----+ ^ 525 | Provider Edge 1 Provider Edge 2 | 526 | | 527 |<----------- Emulated Service ----------->| 529 Customer Customer 530 Edge 1 Edge 2 532 Figure 3: PWE3 Signaling Reference Model 534 - The CE (end-to-end) signaling is between the CEs. This signaling 535 includes Frame Relay PVC status signaling, ATM SVC signaling, etc. 537 - The PW/PE signaling is used between the PEs to set up and tear down 538 PWs, including any required coordination of parameters between the 539 two ends. 541 - The PSN Tunnel signaling controls the underlying PSN. An example 542 would be LDP in MPLS for maintaining LSPs. This type of signaling 543 is not within the scope of PWE3. 545 3.2.3. Protocol Stack Reference Model 547 Figure 4 below shows the protocol stack reference model for PWs. The 548 PW provides the CE with what appears to be a connection to its peer 549 at the far end. Bits or PDUs from the CE are passed through an 550 encapsulation layer. 552 +-------------+ +-------------+ 553 | Emulated | | Emulated | 554 | Service | | Service | 555 | (TDM, ATM, | Emulated Service | (TDM, ATM, | 556 | Ethernet, |<=================================>| Ethernet, | 557 |Frame Relay, | |Frame Relay, | 558 | etc. | | etc. | 559 +-------------+ Pseudo Wire +-------------+ 560 |Encapsulation|<=================================>|Encapsulation| 561 +-------------+ +-------------+ 562 | PSN | PSN Tunnel | PSN | 563 |IP/MPLS/L2TP |<=================================>|IP/MPLS/L2TP | 564 +-------------+ +-------------+ 565 | Physical | | Physical | 566 +-----+-------+ +-----+-------+ 567 | | 568 | IP/MPLS/L2TP Network | 569 | ____ ___ ____ | 570 | _/ \___/ \ _/ \__ | 571 | / \__/ \_ | 572 | / \ | 573 +=========/ |=====+ 574 \ / 575 \ / 576 \ ___ ___ __ _/ 577 \_/ \____/ \___/ \____/ 579 Figure 4: PWE3 Protocol Stack Reference Model 581 3.3. Architecture Assumptions 583 1) The current design is focused on a point-to-point and same-to-same 584 service interface at both end of the PW. Only network 585 interworking will be performed at the edge or the PW. Support for 586 service interworking is for further study. 588 2) The initial design of PWE3 is focused on a single homogenous 589 administrative PWD (e.g. PW over MPLS or PW over IP etc. ONLY). 590 Interworking between different PW types and the support of inter- 591 domain PWs are for further study. 593 3) The design of PW will not perfectly emulate the characteristics of 594 the native service. It will be dependent on both the emulated 595 service, as well as on the network implementation. An AS shall be 596 created for each service to describe the degree of faithfulness of 597 a PW to the native service. 599 4) Only the permanent emulated circuit type (e.g. PVC/PVP) is 600 considered initially. The switched emulated circuit type (e.g. 601 SVC/SVP) will be for further study. 603 5) The creation and placement of the PSN tunnel to support the PW is 604 not within the scope. 606 6) The current PW encapsulation approach considerations are focused 607 on IPv4, IPv6, L2TP and MPLS. Other encapsulation approach is for 608 further study. 610 7) Current PW service applications are focused on Ethernet (i.e. 611 Ethernet II (DIX), 802.3 "raw", Ethernet 802.2, Ethernet SNAP, 612 802.3ac VLAN), Frame Relay, ATM, TDM (e.g. DS1, DS3, E1, SONET/SDH 613 etc.) and MPLS. 615 8) Within the single administrative PWD, the design of the PW assumes 616 the inheritance of the security mechanism that has been applied to 617 the emulated services. No PW specific security mechanism will be 618 specified. 620 3.4. Suitable Applications for PWE3 622 626 When considering PWs as a means of providing a service, the following 627 questions regarding the application must be considered. 629 - Preservation of Order - Does the application require in-order 630 delivery of data? Emulation of an application that requires in- 631 order delivery over a PSN that does not guarantee such delivery may 632 be difficult. 634 - Preservation of Timing - Does the application require fine-grain 635 preservation of timing? If so, the adaptation may be complicated 636 by providing such timing where it is not normally available. 638 - Natural Delineation - What is the "natural" boundary for 639 delineation of data for encapsulation? (Note: For bit/byte- 640 oriented services, such as TDM emulation, this "natural" 641 delineation may not necessarily be the overriding consideration for 642 determining the best "chunk" for packetizing the service.) 644 - Packet Size - Are the encapsulated packets variable or fixed in 645 size? 646 - Data Rate - Is the data rate presented at the interface fixed or 647 variable? 649 Figure 5 below shows a summary of the applications relevant to PWs, 650 along with a comparison of their attributes. 652 +------------+--------+--------+------------+--------+--------+ 653 |Attribute ->|Preserve|Preserve| "Natural" | Packet | Data | 654 |Application | Order | Timing | Delineation| Size | Rate | 655 +------------+--------+--------+------------+--------+--------+ 656 |T1/E1/T3/E3 | yes | yes |125 us frame| fixed | fixed | 657 +------------+--------+--------+------------+--------+--------+ 658 |SONET/SDH | yes | yes |125 us frame| fixed | fixed | 659 +------------+--------+--------+------------+--------+--------+ 660 |Frame Relay | yes | no | frame |variable|variable| 661 +------------+--------+--------+------------+--------+--------+ 662 |ATM AAL1 | yes | yes | cell | fixed | fixed | 663 +------------+--------+--------+------------+--------+--------+ 664 |ATM AAL2 | yes | yes | cell | fixed |variable| 665 +------------+--------+--------+------------+--------+--------+ 666 |ATM AAL5 | yes | no |cell or PDU |variable|variable| 667 +------------+--------+--------+------------+--------+--------+ 668 |Ethernet | yes | no | frame |variable|variable| 669 +------------+--------+--------+------------+--------+--------+ 671 Figure 5: Summary of Applications and Attributes 673 4. Layer 1 (Circuit) Applications 675 For circuit applications the entire bit stream (or at least the 676 payload) needs to be recreated at the far end of the PW. As with ATM 677 CES, the physical layer coding is terminated and re-generated on the 678 far end. In addition, framing may be terminated and regenerated, 679 depending on the application. 681 4.1. Reference Model 683 Figure 6 below shows a pair of T1s being carried over a TDM/SONET 684 network. The node marked "M" is an M13 multiplexer, while the nodes 685 marked "S" are SONET Add-Drop Multiplexers (ADMs). Note that the 686 physical interface of the circuit may change without affecting the 687 circuit. For example, the T1s in Figure 6 below enter the network as 688 physical T1s but exit the network as Virtual Tributaries (VTs) in a 689 physical OC12. 691 SONET/TDM Network 692 ____ ___ ____ 693 _/ \___/ \ _/ \__ 694 +------+ Physical / \__/ \ 695 |Site A| T1 / +---+ DS3 \ Hub Site 696 |T1 #1=|=================|\M/|-------------+-----+ \ OC12+------+ 697 | | \ |/ \|=============|\ /| \----| | 698 +------+ /\ +---+-------------| \ / |========|=T1 #1| 699 / | S | / | | 700 +------+ Physical/ +---+-------------| / \ |========|=T1 #2| 701 |Site B| T1 \ |\S/|=============|/ \| \----| | 702 |T1 #2=|=================|/ \|-------------+-----+ / +------+ 703 | | \ +---+ OC3 __ / 704 +------+ \ __/ \ / 705 \ ___ ___ / \_/ 706 \_/ \____/ \___/ 708 Figure 6: T1/SONET Example Diagram 710 Figure 7 below shows the same pair of T1s being carried over a packet 711 network. Here the emulation is performed by the PEs marked "PE", and 712 the routers marked "R" carry the resulting packets. Note that the 713 PE, routing and/or SONET functions could be combined in the same 714 device. 715 SONET/TDM/Packet Network 716 ____ ___ ____ 717 _/ \___/ \ _/ \__ 718 +------+ Physical /+-+ \__/ \_ 719 |Site A| T1 / | | +---+ \ Hub Site 720 |T1 #1=|=============|P|=| R | +---+ +-+ +-----+ \ OC12+------+ 721 | | \ |E| | |===| | | |=|\ /| \----| | 722 +------+ /\+-+ +---+ | | | | | \ / |========|=T1 #1| 723 / | R |=|P| | S | / | | 724 +------+ Physical/ +-+ +---+ | | |E| | / \ |========|=T1 #2| 725 |Site B| T1 \ |P| | R |===| | | |=|/ \| \----| | 726 |T1 #2=|=============|E|=| | +---+ +-+ +-----+ / +------+ 727 | | \ | | +---+ __ / 728 +------+ \ +-+ __/ \ / 729 \ ___ ___ / \_/ 730 \_/ \____/ \___/ 732 Figure 7: T1 Emulation Example Diagram 734 4.2. Operational Considerations 736 4.2.1. Transparency 738 Circuits such as T1/E1/T3/E3/SONET/SDH lines need a greater degree of 739 transparency than Layer 2 services. These circuits may be carrying 740 the services described in the section on Layer 2 services, but in the 741 Layer 1 scenario the higher layer application is irrelevant and is 742 ignored. In general, these are "bits in, bits out" applications. 744 In this application a circuit or bit stream is encapsulated in fixed- 745 size frames that are sent at a fixed rate. The emulated stream must 746 be delivered in a reliable and predictable fashion to the far end. 747 Absolute delay and delay variation (also called jitter or wander) 748 must be minimized. Excess delay and delay variation may cause 749 problems with the application carried by the TDM/SONET CEs. 751 This encapsulation of TDM data must be transparent. The emulated 752 circuit could be carrying one or more types of data (ATM, Frame 753 Relay, TCP/IP, etc.), voice traffic, video or anything else. The 754 data is not interpreted; it is simply transported. 756 4.2.2. Structured Versus Unstructured Mode For TDM Circuits 758 As discussed in [ATMCES], emulation of a T1, E1 or other circuit can 759 be done in a structured (framed) mode or in an unstructured 760 (unframed) mode. This same distinction can be applied to higher rate 761 circuits such as DS3, E3, and SONET/SDH. 763 Unstructured mode generally involves collecting all bits received 764 from a physical port (including transport framing), and packing them 765 into packets for transport through the PSN. The fact that the 766 received bit stream contains a framed signal is more or less 767 irrelevant to the adaptation function. 769 Structured mode requires the use of a framer to identify and 770 terminate the incoming transport framing, and delineate logical TDM 771 channels within the TDM bit stream for emulation. In addition, TDM 772 framers are generally needed to detect maintenance signals such as 773 Alarm Indication Signal (AIS) and Remote Defect Indication (RDI). 774 Framers are also used to measure various performance parameters such 775 as Errored Seconds, Frame Errored Seconds, etc. Lastly, a framer is 776 needed to generate and terminate the Facility Data Link (FDL) as well 777 as the SONET/SDH Data Communications Channels (DCCs). 779 The capabilities described in the rest of this section (except for 780 LOS) are predicated on the presence of a framer. 782 4.2.3. Fractional T1/E1 784 A fractional T1 or E1 is composed of a number of concatenated DS0s 785 and is sometimes referred to as NxDS0. It may be emulated by 786 replicating the contents of the relevant DS0s at the other end of the 787 tunnel. The value of the other timeslots and/or framing are 788 irrelevant and are not transported in leased line application. Even 789 though the framing is not transported, a framer is still needed to 790 delineate the timeslots for encapsulation. 792 4.2.4. STS-1/Nc 794 The SONET/SDH equivalent to Structured T1/E1 services are STS-1/Nc 795 and their SDH equivalents. For STS-1/Nc services a single SONET 796 timeslot or a concatenation of multiple timeslots is used to carry a 797 single logical circuit. As with structured T1/E1 services, the 798 transport framing (i.e. SONET Section and Line Overhead) is 799 terminated, and only the relevant SONET timeslots are carried through 800 the packet network. A single physical SONET interface can be the 801 source of multiple STS-1/Nc services, each of which may be emulated 802 as an independent PWE3 service. 804 4.2.5. Loopbacks 806 It could be useful for a PE to process loopback messages as defined 807 in [T1.403]. This would allow for isolation of faults in a network. 808 It also facilitates the certification of equipment for operation in a 809 carrier's network. 811 There are also inband loopback commands that are used for voice 812 equipment. These loopback commands are triggered by patterns carried 813 in with the data itself. Voice is limited in the patterns it can 814 present, so it won't falsely mimic the inband loopback command. 815 These inband commands are falling out of favor due to their 816 incompatibility with data services. The inband pattern for the 817 loopback may inadvertently appear in a data stream due to its 818 arbitrary nature. A PE device that implements inband loopbacks must 819 have the capability to disable them. 821 4.2.6. Performance Processing 823 [T1.403] defines a Network Performance Report Message (NPRM) that 824 carry periodic reports on the performance of the link. It would be 825 useful for a PE to generate these messages, as they are frequently 826 used for surveillance and trouble-shooting. 828 4.2.7. LOS/LOF/AIS 830 Figure 8 shows an example for the generation of AIS and RAI. 832 <-- Upstream Downstream --> 834 LOS +-----+ AIS 835 ------X----->|\ /|---------> 836 | \ / | 837 | / \ | 838 <------------|/ \|<--------- 839 RAI/RDI+Data +-----+ Data 841 Figure 8: Generation of AIS and RAI/RDI 843 A TDM multiplexer, SONET ADM, switch or other line terminating 844 equipment (LTE) must respond to an LOS (Loss of Signal), LOF (Loss of 845 Frame) or AIS (Alarm Indication Signal) condition (traditionally 846 known as "red alarms") by generating AIS in the "downstream" 847 direction i.e. the same direction in which the LOS was detected. AIS 848 is conveyed by sending a certain pattern in the data stream. It may 849 also send RAI (or RDI in SONET) in the "upstream" direction i.e. the 850 opposite direction from that where the LOS was detected. See section 851 9 of [T1.403] for more information on T1 AIS and RAI. See section 852 section 6.2.1 in [GR253] for more information on the SONET AIS-L and 853 RDI-L signals. 855 Bandwidth can be saved by suppressing the AIS signal in the emulated 856 stream and sending instead an indication in the control overhead. 857 This also applies to a received AIS signal. [MALIS] discusses the 858 propagation of AIS using the pointer bits in the TDM control word. 860 A device emulating TDM circuit must either replicate the AIS 861 indication or indicate this condition in the control overhead. 863 4.2.8. SONET/SDH STS Unequipped 865 The "STS Unequipped" indication may be treated in a fashion similar 866 to that for LOS/AIS. As discussed in [MALIS], bandwidth can be saved 867 by suppressing the payload in the emulated stream and sending instead 868 an indication in the control overhead. 870 4.3. Encapsulations 872 Encapsulation options for TDM services may be compared on the 873 following criteria. 875 - Timing - TDM services are very sensitive to timing and timing 876 variations ("jitter"). The encapsulation may need to provide 877 additional information (such as [RTP] timestamps) to help convey 878 timing across the PW. 880 - Line Signals - The encapsulation should provide a means to convey 881 signals such as AIS and line conditions such as LOF. 883 - The encapsulation should minimize overhead. 885 4.4. Timing 887 In the recent Ken Burns Jazz television series, it was said of Louis 888 Armstrong that he was very economical with his notes, but that the 889 timing of those notes was everything. The timing of the 890 reconstructed bit stream is similarly important. This section 891 describes the various approaches to this problem. A summary is also 892 provided at the end of the section. 894 4.4.1. Reference Model 896 Consider the example network shown in Figure 9. In this network, CE1 897 and CE2 are connected by a PW provided by PE1, S1, S2 and PE2. 899 +---------------+ +---------------+ 900 | PE1 | | PE2 | G 901 | | | | | 902 | | | | v 903 +---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+ 904 | | | |P| |D| |P| | | | | | | |P| |E| |P| | | | 905 | |<===|h|<:|e|<:|h|<:::| |<::| |<:::|h|<:|n|<=|h|<===| | 906 | | | |y| |c| |y| | | | | | | |y| |c| |y| | | | 907 | C | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | C | 908 | E | | | |S1| |S2| | | | E | 909 | 1 | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | 2 | 910 | | | |P| |E| |P| | | | | | | |P| |D| |P| | | | 911 | |===>|h|=>|n|:>|h|:::>| |::>| |:::>|h|:>|e|=>|h|===>| | 912 | | | |y| |c| |y| | | | | | | |y| |c| |y| | | | 913 +---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+ 914 ^ ^ | | ^ ^ ^ | | | ^ ^ ^ | ^ ^ 915 | | | |B | | | |<------+------>| |D | | | | | | 916 | A | +--+ +--+-C | | | +--+ +--+-E | F | 917 | +---------------+ +-+ +---------------+ | 918 | |I| | 919 | +-+ | 920 | | | 921 +-----------------------------+-----------------------------+ 923 Where: 924 "CEn" is the TDM edge device 925 "PEn" is the PE adaptation device 926 "Sn" is a core switch 927 "A" - "I" are clocks 928 "=" is the T1 Bit Stream 929 ":" is the switched connection 930 "Phy" is a physical interface 931 "Enc" is a PWE3 encapsulation device 932 "Dec" is a PWE3 decapsulation device 934 Figure 9: Timing Recovery Reference Diagram 936 For this application to work, CE2 needs to be clocked (by clock E) at 937 the same frequency as CE1 (which is being clocked by clock A). A 938 jitter correction buffer at PE2 can handle short-term differences 939 between these two clocks, but over time any absolute difference is 940 going to cause this buffer to overflow or underflow. 942 Bits are clocked into an encapsulation function in PE1 according to 943 clock B, which is recovered from the incoming data stream. Clocks A 944 and B will have the same frequency. 946 The bits are packed into frames and clocked out according to clock C. 947 Clock C could be related to clock B, but in most cases these clocks 948 are completely independent. 950 The frames arrive at switch S1, and are clocked out according to the 951 internal oscillator on the output interface of switch S1. The frames 952 will depart at the same average rate at which they arrived, but the 953 instantaneous rate will be different on each side of S1. Note that 954 there could be short-term variations due to congestion, but S1 can't 955 experience long-term congestion with respect to the frames carrying 956 emulated data, or the service won't work. 958 The frames travel on to switch S2, which again forwards them. Note 959 that switch S2 introduces yet another clock, which it uses to 960 transmit the packets toward PE2. Again the average rate is 961 preserved, but the instantaneous rate will vary. 963 The frames arrive at PE2 and are clocked into the decapsulation 964 function when they arrive (using clock D). Note that clock D will 965 have the same average frequency as A and B, but will have short-term 966 variations. The bits are clocked out of the FIFO according to clock 967 E. Clock F at CE2 is recovered from the bit stream and therefore 968 runs at the same frequency as clock E. 970 4.4.2. Recreating the Timing 972 The big question is: where does clock E in Figure 9 come from? There 973 are 5 possibilities, and these are detailed in the following 974 sections. 976 1) Clock E is derived from an external source such as clock I or B 977 (indirectly via A) at CE1 and G (indirectly via H) at CE2. This 978 method is described in the "External Timing" section below. 980 2) Clock E could be derived from Clock I and the pointers. This 981 approach is described in the "SONET Pointer Justification" section 982 below. 984 3) Clock E is derived from the average rate of Clock D. This is the 985 "Adaptive Timing" scenario described in a subsequent section. 987 4) Clock E is derived from a combination of the local oscillator at 988 PE2 and received SRTS timestamps. The "Differential (SRTS)" 989 section below describes this approach. 991 5) Clock E is derived from inband RTP timestamps. This method is 992 discussed in the "RTP" section below. 994 4.4.2.1. External Timing 996 The simplest method for communicating timing from one end of a system 997 to the other is an external timing source, such as clock I in Figure 998 9. This external timing source is normally a T1 or E1, but it could 999 be delivered via SONET or a GPS receiver. Its 8 KHz frame rate is 1000 extracted and used to directly clock the reconstructed data streams, 1001 or as an input to a phase-locked loop to synthesize the desired 1002 clock. The drawback to this method is that a common external clock 1003 is not commonly available in a data network or in a multi-carrier 1004 network. 1006 Note that clock I may actually be two separate clocks of a particular 1007 accuracy or stratum. The difference in frequency will eventually 1008 cause the FIFO to slip, but if the clock is of a high enough accuracy 1009 then the slips will be very infrequent. For example, a stratum 1 1010 clock is accurate to one part in 10**11 [G.811]. This gives a 1011 frequency slip rate of 15.4**-6 bit-slip/sec: 1013 slip rate = 1.544 Mbps * 10**-11 1014 = 15.4**-6 bit-slip/sec 1016 Taking the reciprocal yields 18 hours/bit-slip: 1018 bit slip period = 1 / ( 15.4**-6 bit-slip/sec * 3600 s/h) 1019 = 18 hours/bit-slip. 1021 A typical multiplexer has a buffer that is two frames deep. Assuming 1022 that it starts out centered, the expected time for a slip would be 1023 almost 5 months: 1025 frame slip period = 18 hours/bit-slip * 193 bits/frame 1026 = 3474 hours 1027 = 145 days 1028 = 4.8 months 1030 This slip rate could be higher or lower depending on the bit rate, 1031 clock accuracy and the depth of the FIFO. 1033 4.4.2.2. SONET Pointer Justification 1035 SONET defines layers of pointers that allow for the multiplexing and 1036 transmission of asynchronous signals. These pointers convey the 1037 timing of the carried signal with respect to the timing of the 1038 encapsulating signal. Each SONET ADM must manipulate these pointers 1039 to preserve the timing. This method has the advantage of being well- 1040 defined and understood. 1042 One way to apply this method to a packet-based network would be to 1043 ensure that all of the links on a given path are synchronous. This 1044 would be difficult for Gigabit Ethernet or POS links. 1046 Another way would be for each router to update the pointers as the 1047 packet traversed the router. This would be compute intensive. 1049 The method defined in [MALIS] requires pointer manipulation only at 1050 the end points. It does require an external clock as a reference for 1051 the pointer adjustments. 1053 4.4.2.3. Adaptive Timing 1055 Adaptive timing is used when an external reference is not available. 1056 [ATMCES] describes adaptive timing as follows: 1058 The adaptive technique does not require a network-wide 1059 synchronization signal to regenerate the input Service 1060 clock at the output IWF. A variety of techniques could be 1061 used to implement Adaptive clock recovery. For example, 1062 the depth of the reassembly buffer in the output IWF could 1063 be monitored: 1065 1. When the buffer depth is too great or tends to increase 1066 with time, the frequency of the Service clock could be 1067 increased to cause the buffer to drain more quickly. 1069 2. When the buffer contains fewer than the configured 1070 number of bits, the Service clock could be slowed to 1071 cause the buffer to drain less quickly. Wander may be 1072 introduced by the Adaptive clock recovery technique if 1073 there is a low-frequency component to the Cell Delay 1074 Variation inserted by the ATM network carrying cells 1075 from the input to output IWF. 1077 Careful design is required to make adaptive timing work 1078 well. The instantaneous buffer depth must be filtered to 1079 extract the average frequency and to reject the jitter and 1080 wander. 1082 Adaptive timing is ideal for many network applications where there is 1083 no external timing reference available (needed for SRTS), and where 1084 the packet rate is decoupled from the line rate (as in a routed 1085 network). Adaptive timing may not meet the requirements of [G.823], 1086 [G.824] and other similar specifications. 1088 4.4.2.4. Differential (SRTS) 1090 [ATMCES] describes the SRTS (Synchronous Residual Time Stamp) method: 1092 The SRTS technique measures the Service Interface input 1093 clock frequency against a network-wide synchronization 1094 signal that must be present in the IWF, and sends 1095 difference signals, called Residual Time Stamps, in the 1096 AAL1 header to the reassembly IWF. At the output IWF, the 1097 differences can be combined with the network-wide 1098 synchronization signal to re-create the input Service 1099 Interface clock. 1101 The requirement for a network-wide signal is reasonable in a Telco or 1102 SONET environment, where such clocks are commonly available. It may 1103 be problematic in a packet network. 1105 Here is the correspondence between the clocks in Figure 9 1106 and.[I.363.1]. 1108 Description I.363.1 Figure 9 1109 ------------------------------------------ 1110 Service Clock Fs A, B 1111 Network Clock Fn C 1112 Derived Reference Fnx Based on C 1114 4.4.2.5. RTP 1116 [RTP] uses an absolute timestamp to play out the bits at the same 1117 rate that they were received and packetized. RTCP (RTP Control 1118 Protocol) provides a means to synchronize the transmit and receive 1119 clocks. 1121 4.4.2.5.1. RTP Timestamps 1123 Section 4 of [RTP] defines a timestamp that is either 32-bits or 1124 64-bits in size: 1126 Wallclock time (absolute time) is represented using the 1127 timestamp format of the Network Time Protocol (NTP), which 1128 is in seconds relative to 0h UTC on 1 January 1900 [NTP]. 1129 The full resolution NTP timestamp is a 64-bit unsigned 1130 fixed-point number with the integer part in the first 32 1131 bits and the fractional part in the last 32 bits. In some 1132 fields where a more compact representation is appropriate, 1133 only the middle 32 bits are used; that is, the low 16 bits 1134 of the integer part and the high 16 bits of the fractional 1135 part. The high 16 bits of the integer part must be 1136 determined independently. 1138 A 32-bit absolute time stamp with a 16-bit fractional part would give 1139 a 15 us granularity (= 1/65535), which is too coarse for circuit 1140 emulation. This means that the 64-bit timestamp must be used, with a 1141 granularity of 23 ns. 1143 The transmit timestamps are created according to clocks B and C at 1144 PE1 and interpreted according to clocks D and E at PE2. These two 1145 oscillators will vary by some amount, even if they are very accurate. 1146 This drift means that RTCP, NTP or some other means must be used to 1147 synchronize the clocks at each end. 1149 4.4.3. Summary of Timing Recovery Methods 1151 All of the previously described methods for timing recovery can be 1152 made to work for Layer 1 circuit services. How then can we compare 1153 them? Here are some criteria: 1155 - Is an external timing source required? This might be a direct 1156 timing source as described in "External Timing", or it could be an 1157 indirect source as with SRTS. 1159 - Must the PE synthesize clocks? Synthesis of clocks generally 1160 requires a Phase-Locked Loop (PLL) to create one clock from 1161 another. 1163 - Is the method provably correct? Some methods such as external 1164 timing and SRTS can be proven to meet specifications. The 1165 performance of others, such as adaptive timing, is more dependent 1166 on particular implementations. 1168 Figure 10 below shows a summary of the methods for timing recovery. 1170 +-----------------------------+------+-----+-----+----+-----+ 1171 | Method->| Ext. |SONET|SRTS |RTP/|Adap-| 1172 |Parameter |Source| Ptr | |RTCP|tive | 1173 +-----------------------------+------+-----+-----+----+-----+ 1174 |External timing required? | yes | yes | yes | no | no | 1175 |Clock synthesis? | no | yes | yes | yes| yes | 1176 |Provably correct? | yes | yes | yes | ? | ? | 1177 +-----------------------------+------+-----+-----+----+-----+ 1179 Figure 10: Summary of Timing Recovery Methods 1181 5. Layer 2 (Packet/Cell) Applications 1183 5.1. Layer 2 PW Reference Model 1185 Figure 11 below shows the reference model for Layer 2 PWs. The Layer 1186 2 emulated protocols/services include ATM VCC, ATM VPC, Frame Relay 1187 DLCI, IEEE 802.1Q VLAN, IEEE 802.3x link, etc. The nodes marked "S" 1188 are protocol-specific switches e.g. Frame Relay switches. 1190 Carrier A Carrier B 1191 ____ ___ 1192 Layer 2 _/ \___/ \ ___ 1193 +-------+ Link / \____ / \__ Layer 2 1194 |Site A |---------/ +---+ \ / \ Link 1195 | CE#1=|===============|\S/| || +-----+ \ +------+ 1196 | |--------\ |/ \|===============|\ /| \--|Site C| 1197 +-------+ \ +---+ || | \ / |=====|=CE#3 | 1198 / || | S | / | | 1199 +-------+ / +---+ || | / \ |=====|=CE#4 | 1200 |Site B |--------\ |\S/|===============|/ \| \--| | 1201 | CE#2=|===============|/ \| || +-----+ _/ +------+ 1202 | |---------\ +---+ / \__ / 1203 +-------+ \ / \ _/ 1204 \ ___ ___ \ \_/ 1205 \_/ \___/ \___/ 1207 Figure 11: Layer 2 Interconnect Reference Model 1209 Figure 12 below shows the reference model for PW emulation of Layer 2 1210 services. 1212 Carrier A Carrier B 1213 ____ ___ 1214 Layer 2 _/ \___/ \ ___ 1215 +-------+ Link /+-+ \____ / \__ Layer 2 1216 |Site A |--------/ |P| +---+ +---+ \ / \ Link 1217 | CE#1=|==========|W|=| R | | R | +-+ | | +-----+ \ +------+ 1218 | |-------\ |E| | |==| |=| |=|==|=|\ /| | |Site C| 1219 +-------+ \ +-+ +---+ +---+ |P| | | | \ / |=|===|=CE#3 | 1220 /\ |W| | | | F | | | | 1221 +-------+ / +-+ +---+ +---+ |E| | | | / \ |=|===|=CE#4 | 1222 |Site B |-------\ |P|=| R |==| R |=| |=|==|=|/ \| | | | 1223 | CE#2=|==========|W| | | | | | | | | +-----+ | +------+ 1224 | |--------\ |E| +---+ +---+ +-+ | | | 1225 +-------+ \+-+ / \_______/ 1226 \ / 1227 \ _ __ / 1228 \_/ \___/ \____/ 1230 Figure 12: Layer 2 PW Emulation 1232 5.2. Ethernet 1234 5.2.1. Reference Model Scope 1236 PW carriage of Ethernet operates as point-to-point trunking in a non- 1237 shared medium. The Ethernet interface can operate in a half-duplex 1238 or full-duplex mode. Control functions such as IEEE 802.3 Carrier 1239 Sense Multiple Access with Collision Detection (CSMA/CD)[802.3] and 1240 IEEE 802.1D Spanning Tree [802.1D] are not applicable nor within the 1241 scope of PWs. However, the PW shall conform to the service 1242 definitions as defined in IEEE 802.1P,Q [802.1Q], as required. Also, 1243 it shall support all Ethernet framing i.e. Ethernet Frame and IEEE 1244 802.3x including IEEE 802.3ac VLAN Tagging [802.3] as well as Jumbo 1245 Frame. 1247 5.2.2. Operational Considerations 1249 5.2.2.1. Operational Modes 1251 The design of the Ethernet PW must consider the support of the two 1252 operational modes in this framework. Both modes shall be supported 1253 for all Ethernet interfaces, i.e. from 10 Mbps to 10,000 Mbps, and 1254 the design of the Ethernet PW functions shall be agnostic to the 1255 Ethernet's link capacity. Both modes shall transparently support the 1256 address resolution protocols, i.e. ARP, InverseARP, proxy ARP and 1257 Ethernet-based control protocol (e.g. Generic Attribute Registration 1258 Protocol (GARP), GARP VLAN Registration Protocol (GVRP) etc.). 1260 - Opaque Trunking - In this mode, the ingress PE shall relay all of 1261 the traffic from an Ethernet port into the PW. 1263 - Transparent Trunking - This mode is particularly designed for 1264 support of Virtual LANs (VLAN). VLAN types include Port-based 1265 VLANs, MAC-Address-Based VLANs, IP-Based VLANs, 802.1Q Tag-based 1266 VLANs and 802.10 Security-based VLANs. 1268 The ingress PE may pay attention to the MAC header and other 1269 relevant VLAN classification information based on the configuration 1270 policy. The Ethernet PW shall carry multiple VLANs traffic and can 1271 extend VLANs across the PWD. In the case when 802.1Q Tag-based 1272 VLAN is configured, if the received frame is tagged with a NULL 1273 VLAN_ID, it will be associated with the VLAN equal to the Port's 1274 default VLAN. At frame transmission, all frames that are 1275 associated with 802.1Q Tag-based VLAN shall be tagged except for 1276 those assigned for the default VLAN. 1278 The PE may provide translation of the VLAN_ID in order to 1279 facilitate deployment. Note that this does not increase the 1280 VLAN_ID space, so it has no effect on scalability. 1282 5.2.2.2. Quality Of Service Support Considerations 1284 The Ethernet AS shall describe the faithfulness of the PW with 1285 respect to these attributes described in IEEE 802.1p [802.1Q]. 1287 - Service Availability - Service availability is measured as ratio 1288 between times when MAC service is unavailable and when it is 1289 available. 1291 - Frame Loss - The MAC service does not provide guaranteed delivery 1292 of service data units. However, the Ethernet PW system should 1293 consider monitoring frame loss. 1295 - Frame Misorder - The MAC service does not permit reordering frames 1296 within the same user-priority for a source and destination address 1297 pair. 1299 - Frame Duplication - The MAC service does not permit duplicating 1300 frames. 1302 - Transit Delay Performance - IEEE 802.1p [802.1Q] defines frame 1303 transit delay is the elapsed time between an MA_UNITDATA.request 1304 and corresponding MA_UNITDATA.indication on a successful transfer. 1306 - Undetected Frame Error Rate - By using the Frame Checksum (FCS) 1307 calculation for each frame, the undetected frame error rate should 1308 be low. 1310 - Maximum Service Data Unit Size - The maximum service data unit size 1311 is dependent on the access media used. In general, it is the 1312 lowest common denominator of the two adjacent Ethernet interface. 1314 - Priority Tags and Traffic Classes - IEEE 802.1p defines eight 1315 traffic classes (priority). The PRI bits on the VLAN fields should 1316 be carried transparently over the PW. COS differentiation on the 1317 PW level based on the received 802.1p bits is possible but is out- 1318 of-scope. 1320 5.3. Frame Relay 1322 5.3.1. Reference Model 1324 Frame Relay service offerings often have a different physical format 1325 and speed at each end of the link. For example, a hub and spoke 1326 deployment of Frame Relay might provide fractional T1 access at the 1327 spokes and a clear channel T3 to the hub. The Virtual Circuits (VCs) 1328 are aggregated by switches in the Frame Relay network. This is shown 1329 in figure 13 below, where the Frame Relay switches are marked with an 1330 "F". 1332 Wide Area Frame Relay Network 1334 Carrier A Carrier B 1335 ____ ___ 1336 Fractional _/ \___/ \ ___ 1337 +------+ T1 / \____ / \__ 1338 |Site A|-----------/ +---+ \ / \ Hub Site 1339 |VC #1=|=================|\F/| || +-----+ \ DS3+------+ 1340 | |----------\ |/ \|===============|\ /| \---| | 1341 +------+ \ +---+ || | \ / |======|=VC #1| 1342 /\ || | F | / | | 1343 +------+ / +---+ || | / \ |======|=VC #2| 1344 |Site B|----------\ |\F/|===============|/ \| \---| | 1345 |VC #2=|=================|/ \| || +-----+ _/ +------+ 1346 | |-----------\ +---+ / \__ / 1347 +------+ Trans- \ / \ _/ 1348 Atlantic E1 \ ___ ___ \ \_/ 1349 \_/ \___/ \___/ 1351 Figure 13: Frame Relay Example Model 1353 Figure 14 shows an emulated network, where Carrier "A" is providing a 1354 transparent Frame Relay emulation connection to Carrier "B". 1356 Wide Area Frame Relay/Router Network 1358 Carrier A Carrier B 1359 ____ ___ 1360 Fractional _/ \___/ \ ___ 1361 +------+ T1 /+-+ \____ / \__ 1362 |Site A|------------/ | | +---+ \ / \ Hub Site 1363 |VC #1=|==============|P|=| R | +---+ +-+ || +-----+ \ DS3+------+ 1364 | |-----------\ |E| | |==| |=| |====|\ /| \---| | 1365 +------+ \ +-+ +---+ | | | | || | \ / |======|=VC #1| 1366 / \ | R | |P| || | F | / | | 1367 +------+ / +-+ +---+ | | |E| || | / \ |======|=VC #2| 1368 |Site B|----------\ |P| | R |==| |=| |====|/ \| \---| | 1369 |VC #2=|==============|E|=| | +---+ +-+ || +-----+ / +------+ 1370 | |-----------\ | | +---+ / \_ / 1371 +------+ Trans- \ +-+ / \ _/ 1372 Atlantic E1 \___ ___ __ \ \__/ 1373 \_/ \___/ \__/ 1375 Figure 14: Frame Relay Emulation Example Diagram For Transparent 1376 Emulation 1378 Here the emulation is performed by the PEs marked "PE", and the 1379 resulting packets are carried by the routers marked "R". In this 1380 case, the emulated VCs can transparently carry the PVC status 1381 signaling (if any) and need not perform any higher layer function. 1382 Also, note that the emulation and routing functions could be combined 1383 in the same device. 1385 If the Frame Relay switches are to be completely eliminated (as shown 1386 in figure 15 below), then the emulation service must implement Frame 1387 Relay PVC status signaling and/or connection signaling for SVCs. As 1388 previously noted, the PE and routing functions could be combined in 1389 the same device. 1391 Wide Area Frame Relay/Router Network 1393 Carrier A Carrier B 1394 ____ ___ 1395 Fractional _/ \___/ \ _____ 1396 +------+ T1 /+-+ \____ / \__ 1397 |Site A|----------/ | | +---+ \ / \ Hub Site 1398 |VC #1=|============|P|=| R | +---+ +-+ || \ DS3 +------+ 1399 | |---------\ |E| | |==| |=| | || \----| | 1400 +------+ \ +-+ +---+ | | | |====================|=VC #1| 1401 /\ | R | |P| || / | | 1402 +------+ / +-+ +---+ | | |E|====================|=VC #2| 1403 |Site B|---------\ |P| | R |==| |=| | || \----| | 1404 |VC #2=|============|E|=| | +---+ +-+ || _/ +------+ 1405 | |----------\ | | +---+ / \__ / 1406 +------+ Trans- \+-+ / \ _/ 1407 Atlantic E1 \___ ___ _ \ \__/ 1408 \_/ \__/ \___/ 1410 Figure 15: Frame Relay Emulation Example Diagram For Non-Transparent 1411 Emulation 1413 5.3.2. Operational Considerations 1415 Frame Relay provides a connection-oriented circuit-based carriage of 1416 variable-sized frames. There are two types of virtual circuits 1417 supported in Frame Relay: Permanent Virtual Circuits (PVCs) and 1418 Switched Virtual Circuits (SVCs). The following sections describe 1419 the considerations to support the operation of Frame Relay over the 1420 PW. 1422 5.3.2.1. Frame Sequence 1424 The PW must deliver frames in the proper sequence. 1426 5.3.2.2. Frame Size 1428 In general, the maximum frame size for Frame Relay is 1600 bytes per 1429 [FRF.1.2]. This can be made larger in some implementations. If the 1430 MTU of the PW is less than (1600 bytes - size of PW headers), a 1431 fragmentation and reassembly mechanism may be needed. 1433 5.3.2.3. End-to-End Characteristics 1435 [FRF.5] and [FRF.13] define a set of traffic parameters to support 1436 Service Level Agreements (SLAs). The design of the PW may be 1437 required to preserve these end-to-end transport characteristics. 1439 5.3.2.4. Connection Management and Congestion Control 1441 Each Frame Relay header contains some connection management 1442 information, including 1444 - a command/response (CR) bit 1446 - a discard eligibility (DE) bit 1448 - a connection ID (DLCI) 1450 - an address extension indicator (EA) 1452 - Forward/Backward Congestion Notification (FECN/BECN). Figure 16 1453 shows an example of how BECN and FECN are sent. 1455 --Congestion-> 1456 +-----+ Data+FECN 1457 ------------>|\ /|---------> 1458 | \ / | 1459 | / \ | 1460 <------------|/ \|<--------- 1461 BECN+Data +-----+ Data 1463 Figure 16: Generation of BECN and FECN 1465 All of this information is vital to the integrity of the Frame Relay 1466 circuit. The Frame Relay PW AS must define a means to preserve such 1467 information across the PWD. 1469 5.3.2.5. Link Management Support 1471 Frame Delay defines a set of link management functions for PVC Status 1472 Management as specified in [T1.617D] and [Q.933A]. Link Management 1473 runs on a dedicated PVC; therefore, its operation does not impact 1474 actual user data. The management functions include: 1476 - a heartbeat exchange that verifies that the link is operational 1478 - a report regarding the status of one or more individual DLCIs 1480 For some networks, such as the one shown in Figure 15, this link 1481 management is the only means to verify the end-to-end integrity of 1482 the Frame Relay virtual circuit. The PE may required to emulate such 1483 functions. These functions will be transparent to the underlying 1484 network. 1486 Another important consideration is that there should be some 1487 coordination between the PW's link status and the associated Frame 1488 Relay VCs. For example, it might be necessary to tear down the VCs 1489 in the presence of a network fault. 1491 5.3.2.6. DLCI Association 1493 There are two scopes of DLCI addressing that have been defined by 1494 ANSI and ITU-T: Local and Global DLCIs. 1496 - Local DLCI addressing means that DLCI numbers are only significant 1497 at one end of a Frame Relay virtual circuit. 1499 - Global DLCI addressing is an extension to PVC status management 1500 that allows a DLCI number to have universal significance. A global 1501 DLCI identifies the same VC at both ends of the network. 1503 In the case when the DLCI is locally significant, the management of 1504 the PWD must provide a mechanism to coordinate the DLCIs at the two 1505 ends of the PW. The association can be done via signaling or 1506 configuration. 1508 5.3.2.7. Multiplexing VCs over PWs 1510 To preserve PW tunnel space and to enhance scalability of PWs, it 1511 would be very valuable to allow one or more VCs to be multiplexed 1512 onto the same PW. One scenario might be to associate an entire Frame 1513 Relay logical interface to a PW. Another possibility is that the 1514 assignment of VCs to the PW could be done via signaling or 1515 management. In either of these cases, the DLCI for each frame would 1516 need to be preserved across the PW. 1518 If such multiplexing approach is used, the earlier discussion related 1519 to the packet sequencing, end-to-end characteristics, SLA 1520 preservation and link status management, shall be addressed with the 1521 same considerations. 1523 5.3.2.8. Signaling Transparency 1525 Since Frame Relay supports SVCs, the PE may need to support signaling 1526 interworking at the PWES. InverseARP frames should be passed on 1527 without interpretation. In either case, these frames shall be 1528 transparent to the underlying PSN. 1530 5.3.2.9. Soft PVC Support 1532 One type of connection service that is provided by Frame Relay 1533 networks is called a Soft PVC (SPVC). A SPVC may be considered to be 1534 composed of three parts: two peer-to-peer PVCs at each side of the 1535 core, and a SVC between them. 1537 Figure 17 shows the SPVC interconnection example. 1539 +---+ +---+ +---+ +---+ +---+ 1540 | E |========| C |:::::::| C |:::::::| C |======| E | 1541 +---+ +---+ +---+ +---+ +---+ 1543 Where: 1544 "E" is the edge switch 1545 "C" is the core switch 1546 "=" is the permanent connection 1547 ":" is the switched connection 1549 Figure 17: Example of an SPVC Over a Frame Relay Network 1551 The creation of the SPVC within the core is triggered by detecting 1552 the existence of the PVCs at the edges. This detection is done 1553 either by network management or by some proprietary signaling. 1555 Now consider the case where the core switches are replaced by PEs as 1556 shown in Figure 14. The SVC connection within the core is replaced 1557 by the PW. The PVCs configuration which are maintained by the 1558 ingress and the egress CEs of the PWD should remain the same. The 1559 ingress and egress PEs shall maintain the SPVC behavior such that it 1560 is transparent to the CEs. 1562 5.4. ATM 1564 5.4.1. Reference Model 1566 As far as PWs are concerned, ATM is very similar to Frame Relay. We 1567 will use the same reference network (Figure 13) for ATM as we did for 1568 Frame Relay. Of course, the Frame Relay switches would be ATM 1569 switches instead. Likewise, the PE networks shown in Figures 14 and 1570 15 are applicable to ATM. 1572 5.4.2. Operational Considerations 1574 Like Frame Relay, ATM provides connection-oriented circuit-based 1575 carriage of fixed-size cells. There are two types of virtual circuit 1576 supported in ATM: PVC and SVC. In addition to virtual circuit 1577 connections (VCCs), ATM also supports virtual path connections 1578 (VPCs). There are also permanent virtual paths (PVPs) and switched 1579 virtual paths (SVPs). 1581 ATM carries data in fixed size (53 byte) frames called "cells". 1582 Higher layer frames are adapted to these fixed size cells via ATM 1583 Adaptation Layers (e.g. AAL1, AAL2 and AAL5) and SAR. Different 1584 types of AALs have different cell header formats, and the cells may 1585 contain signaling information. 1587 The following sections describe the set of considerations for PW 1588 support of ATM. 1590 5.4.2.1. Cell Sequence 1592 The PW must deliver cells in the proper sequence. 1594 5.4.2.2. End-to-end Transport Characteristics 1596 The ITU-T [I.356] and the ATM Forum [TM4.0] each define a set of 1597 traffic and QoS parameters. The AS for ATM PWs should specify how 1598 the PW will maintain the end-to-end characteristics for such VCs. 1600 5.4.2.3. ATM SLA 1602 The ITU-T [I.371] defines performance targets for managing ATM 1603 traffic and congestion control. These targets may be used by some 1604 service providers to define their ATM SLAs. The AS for ATM PWs 1605 should specify how SLA transparency will be achieved. 1607 5.4.2.4. Connection Management and Congestion Control 1609 The ATM header contains some connection management and congestion 1610 control information, as defined in [I.371]: 1612 - Cell Loss priority (CLP) 1614 - Connection Identifier (VPI/VCI) 1616 - Payload Type Identifier (PTI) - distinguishes between an OAM 1617 (Operations, Administration and Management) cell and a user cell 1619 - Explicit Forward Congestion Indication (EFCI) 1621 All of this information is vital to the integrity of the ATM circuit. 1622 The ATM PW AS must define a means to preserve such information across 1623 the PWD. 1625 5.4.2.5. OAM Support 1627 ATM OAM functions are defined in the ITU-T standard [I.610]. OAM 1628 cells are used to provide functions like fault management, 1629 performance management and continuity checks. 1631 OAM is implemented differently in VCCs and VPCs. In the case of a 1632 VCC, the OAM cell is sent along the same VC as the user cells. For a 1633 VPC, the OAM cell is sent over a dedicated VC within the VPC. OAM 1634 flows are also classified as end-to-end flows (covering the entire 1635 virtual connection) or as segment flows (covering only parts of the 1636 virtual connection). 1638 The PE may emulate the end-to-end OAM flows by encapsulating the OAM 1639 cells in a PW-PDU. A PE that supports the OAM function should 1640 support coordination between the OAM behavior between the PE peers. 1641 For example, an OAM AIS cell at one end can result in PW signaling 1642 that causes the PW link to go down at the far end. If the PE does 1643 support OAM, the emulation of the OAM function shall be transparent 1644 to the underlying network. 1646 5.4.2.6. ILMI Support 1648 The Integrated Local Management Interface [ILMI] protocol facilitates 1649 network deployment and management in several ways: 1651 - ILMI allows an ATM node to determine the various features supported 1652 by its neighbors (such as type of signaling, size of connection 1653 space etc). 1655 - ILMI allows for smoother administration of ATM addresses through 1656 address registration. 1658 - ILMI facilitates automatic configuration of private interfaces. 1660 - ILMI supports procedures for detecting loss of connectivity through 1661 periodic polling. 1663 For some networks, such as the one shown in Figure 15, ILMI is the 1664 only means to verify the end-to-end integrity of the ATM virtual 1665 circuit. It may be desirable for the PE to emulate such functions. 1666 If supported, these functions must be transparent to the underlying 1667 network. 1669 5.4.2.7. VC Associations 1671 Each ATM connection identifier has local significance only. Local 1672 significance means that each ATM connection identifier (VPI and/or 1673 VCI) is only significant at a local ATM interface, and is independent 1674 from the identifier at the other end of the link. The management of 1675 the PWD must provide a mechanism to coordinate the identifiers at the 1676 two ends of the PW. The association can be done via signaling or 1677 configuration. 1679 5.4.2.8. Multiplexing ATM VCs over PWs 1681 See the discussion in the "Multiplexing VCs over PWs" sub-section of 1682 the previous "Frame Relay" section of this document. 1684 5.4.2.9. ATM Signaling Transparency 1686 See the discussion in the "Signaling Transparency" sub-section of the 1687 previous "Frame Relay" section of this document. 1689 5.4.2.10. Soft PVC Support 1691 See the discussion and figures in the "Soft PVC Support" sub-section 1692 of the previous "Frame Relay" section of this document. 1694 5.4.2.11. Segmentation and Reassembly (SAR) 1696 The bandwidth overhead of the ATM cell is about 10% (= 5 overhead 1697 bytes out of 53 bytes total). For AAL5 traffic [I.363.5], it may be 1698 more efficient in terms of bandwidth to carry the re-assembled AAL5 1699 frames instead of the individual ATM cells. This would involve some 1700 cost in terms of a SAR operation at each end of the PW. In some 1701 cases, especially if OAM is required to be supported over the PW, the 1702 PW may have no choice but to transport the ATM traffic in cell 1703 format. 1705 Whether the ATM traffic is transported in a frame or cell format, it 1706 is the responsibility of the PE to emulate the OAM functions to the 1707 adjacent ATM interface at each end. 1709 6. PW Maintenance 1711 6.1. PW-PDU Validation 1713 It is a common practice to use a checksum, CRC or FCS to assure end- 1714 to-end integrity of frames. The PW service-specific mechanisms must 1715 define whether the packet's checksum shall be preserved across the 1716 PWD or be removed at the ingress PE and then be re-calculated at the 1717 egress PE. The former approach saves work, while the later saves 1718 bandwidth. 1720 For protocols like ATM and Frame Relay, the checksum is only 1721 applicable to a single link. This is because the circuit identifiers 1722 (e.g. Frame Relay DLCI or ATM VPI/VCI) have only local significance 1723 and are changed on each hop or span. If the circuit identifier (and 1724 thus checksum) is going to change as a part of the PW emulation, it 1725 would be more efficient to strip and re-calculate the checksum. 1727 Other PDU headers (e.g. UDP in IP) do not change during transit. It 1728 would make sense to preserve these types of checksums. 1730 The AS for each protocol must describe the validation scheme to be 1731 used. 1733 6.2. PW-PDU Sequencing 1735 One major consideration of PW design is to ensure in-sequence 1736 delivery of packets, if needed. The design of the PW for each 1737 protocol must consider the support of the PSN for in-order delivery 1738 as well as the requirements of the particular application. For 1739 example, MPLS supports connection-oriented transport with a guarantee 1740 of in-order delivery. A sequence number in the PW layer is not 1741 needed when used with MPLS. IP is connectionless and does not 1742 guarantee in-order delivery. When using IP, a PW sequence number may 1743 be needed for some applications (such as TDM). 1745 6.3. Session Multiplexing 1747 One way to facilitate scaling is to increase the number of PWs per 1748 underlying tunnel. There are two ways to achieve this: 1750 - For a service like Relay or ATM, all of the VCs on a given port 1751 could be lumped together. VCs would not be distinguishable within 1752 the PWD. 1754 - Service SDUs could be distinguished within a PW-PDU by port, 1755 channel or VC identifiers. This approach would allow for switching 1756 or grooming in the PWD. 1758 6.4. Security 1760 Each AS must specify a means to protect the control of the PWE and 1761 the PE/PW signaling. The security-related protection of the 1762 encapsulated content of the PW is outside of scope. 1764 6.5. Encapsulation Control 1766 6.5.1. Scalability 1768 Different service types may be required between CEs, Support of 1769 multiple services implies that a range of PWD label spaces may be 1770 needed. If the PWD spans a PSN supporting traffic engineering, then 1771 the ability to supporting label stacking would be desirable. 1773 6.5.2. Service Integration 1775 It may be desirable to design a PW to transport a variety of services 1776 which have different transport characteristics. To achieve this 1777 integration it may be useful to allow the service requirements to be 1778 mapped to the tunneling label in such a way that the PWD can apply 1779 the appropriate service and transport management to the PW. 1781 6.6. Statistics 1783 The PE can tabulate statistics that help monitor the state of the 1784 network, and to help with measurement of SLAs. Typical counters 1785 include: 1787 - Counts of PW-PDUs sent and received, with and without errors. 1789 - Counts of PW-PDUs lost (TDM only). 1791 - Counts of service PDUs sent and received, with and without errors 1792 (non-TDM). 1794 - Service-specific interface counts. 1796 These counters would be contained in a MIB, they should not replicate 1797 existing MIB counters. 1799 6.7. Traceroute 1801 Tracing functionality is desirable for emulated circuits and 1802 services, because it allows verification and remediation of the 1803 operation and configuration of the forwarding plane. [BONICA] 1804 describes the requirements for a generic route tracing application. 1805 Applicability of these requirements to PWE3 is an interesting 1806 problem, as many of the emulated services have no equivalent 1807 function. In general, there is not a way to trace the forwarding 1808 plane of an TDM or Frame Relay PVC. ATM does provide an option in 1809 the loopback OAM cell to return each intermediate hop (see [I.610]). 1811 There needs to be a mechanism through which upper layers can ask 1812 emulated services to reveal their internal forwarding details. A 1813 common mechanism for all emulated services over a particular PSN may 1814 be possible. For example, if MPLS is the PSN, the path for a VC LSP 1815 could be revealed via the signaling from the underlying TE tunnel 1816 LSP, or perhaps via the proposed MPLS OAM. However, when we are 1817 trying to trace the entire emulated service, starting from the CE 1818 (e.g. an ATM VCC), then a uniform approach probably will not work and 1819 different approaches would be required for different emulated 1820 services. 1822 6.8. Congestion Considerations 1824 [RFC2914] describes how devices connected to the Internet should 1825 handle congestion. The discussion of congestion with respect to PWE3 1826 will be broken into two sections: CBR applications and VBR 1827 applications. 1829 6.8.1. VBR Applications 1831 VBR applications include Ethernet, Frame Relay, and ATM (other than 1832 AAL CES). During periods of congestion the PE may be able to take 1833 action to communicate to the CE the need to slow down. 1835 6.8.1.1. Frame Relay 1837 In the presence of congestion, the PE could perform several actions. 1838 These are the same actions that a Frame Relay switch might take. If 1839 available, a measure of the degree of congestion would be useful. 1841 - While a service provide may define an SLA for a Frame Relay 1842 Service, Frame Relay itself does not have a guarantee of delivery. 1843 Given this fact, the PE could do nothing in the face of congestion. 1844 The Frame Relay application at the CE would then have to detect 1845 congestion and act appropriately. 1847 - Frame Relay defines BECN as an indication to a Frame Relay device 1848 that traffic that it sent is experiencing congestion. See Figure 1849 16 for an example of how BECN is sent. For mild congestion, the PE 1850 could send BECN back to the CE. The CE could then reduce the 1851 amount of traffic being sent. It is worth nothing that many Frame 1852 Relay devices ignore BECN. 1854 - The CE could also send FECN in the direction in which congestion is 1855 occurring. See Figure 16 for an example of how FECN is sent. 1857 - During congestion, the PE could discard all frames with DE set 1859 - If the PE was aware of the CIR for the VCs, it could drop any 1860 traffic in excess of CIR. 1862 - For severe congestion the PE could take the interface down. If the 1863 PE was generating the PVC status signaling then these messages 1864 could be used to convey the problem to the CE. This approach is 1865 not elegant and may not work well with existing Frame Relay 1866 applications. 1868 6.8.1.2. ATM 1870 ATM has a forward notification of congestion (EFCI), but unlike Frame 1871 Relay there is no backwards notification. This leaves the following 1872 choices of action. These are the same actions that an ATM switch 1873 might take. 1875 - Do nothing and let the ATM application at the CE handle the 1876 problem. This may work for some applications, but it will make it 1877 difficult for service providers to guarantee a high QoS on the VC. 1879 - If the PE was aware of the traffic parameters for the VCs, it could 1880 drop any traffic that was out of profile. 1882 - For severe congestion the PE could take the interface down. This 1883 may be worse than doing nothing. 1885 6.8.1.3. Ethernet 1887 A PE providing a PW to an Ethernet CE could react to congestion in 1888 one of the following ways. 1890 - A PE could use Ethernet flow control during congestion by sending a 1891 PAUSE frame as described in Annex 31B of [802.3]. 1893 - A PE could do nothing and let the Ethernet application at the CE 1894 handle the problem. 1896 - For severe congestion the PE could take the interface down. This 1897 may be worse than doing nothing. 1899 6.8.2. CBR Applications 1901 CBR applications include layer 1 applications such as emulated 1902 TDM/SONET streams, as well as layer 2 applications such as ATM AAL1 1903 CES. These applications present a constant load on the network at 1904 all times. They cannot slow down; they are either running at full 1905 speed, or they are impaired. If congestion causes an excessive 1906 number of packets to be lost, the PE could take down the interface 1907 and send AIS to the CE. There is probably not much point in doing 1908 this if the PE is operating in an unstructured mode, as the framer in 1909 the CE will probably declare a LOS condition anyway. A PE operating 1910 in a structured (framed) mode would always send a clean frame pattern 1911 to the CE, so it might be desirable to send AIS to notify the CE that 1912 there are problems with the PW. 1914 7. Packet Switched Networks 1916 This section discusses various types of PSNs for providing the PW 1917 transport. The areas of considerations are: 1919 - Explicit Multi-protocol Encapsulation Identifier 1921 - Transport Integrity 1923 - Traffic Engineering Ability 1925 - Session Multiplexing 1927 - Flow and Congestion Control 1929 - Packet Ordering 1931 - Tunnel Maintenance 1933 - Scalability 1935 - Overhead 1937 - QoS and Traffic Management 1939 7.1. IP 1941 Below is a description of the aspects of the Internet Protocol [IP]. 1943 Explicit MP Encap ID No support for a full range of multi-service 1944 protocols e.g. there is no protocol type 1945 assigned for ATM or MPLS. 1947 Transport Integrity IP has a checksum over the header but not 1948 over the payload. 1950 Traffic Engineering The TOS bits may be used as DiffServ code 1951 points. 1953 Session Multiplexing No support for session multiplexing. 1955 Packet Order No support for preservation of order. 1957 Tunnel Maintenance Protocols such as L2TP may be used to 1958 establish tunnels using IP packets. 1960 Flow/Congestion Control No built-in flow control to manage 1961 congestion. IP relies on the upper layer 1962 protocol, e.g. TCP, to perform the 1963 congestion management. 1965 Scalability It would be hard to imagine a protocol more 1966 scalable than IP. 1968 Transport Overhead Minimum of 20-byte header. 1970 QoS/Traffic Management No built-in QoS and traffic management. 1971 However, one can apply DiffServ to select a 1972 per-hop behavior for a class of traffic. 1974 7.2. L2TP 1976 Layer 2 Tunneling (L2TP) [L2TP] provides a virtual extension of PPP 1977 across an IP PSN. 1979 Explicit MP Encap ID Supports any routed protocol, e.g. IP, IPX 1980 and AppleTalk that is supported by PPP. 1982 Transport Integrity Support a checksum for the entire 1983 encapsulated frame. 1985 Traffic Engineering No companion traffic engineering mechanism 1986 to support L2TP tunnel establishment. 1988 Session Multiplexing Supports two levels of session multiplexing 1989 via the use of the "tunnel-id" and "session- 1990 id" fields. 1992 Packet Order By supporting the optional sequence number, 1993 packet re-ordering can be done at the PWE 1995 Tunnel Maintenance L2TP uses control messages to establish, 1996 terminate and monitor the status of the 1997 logical PPP sessions. These are independent 1998 of the data messages. L2TP also provides an 1999 optional keep-alive mechanism to detect non- 2000 operational tunnel. 2002 Flow/Congestion Control L2TP defines flow and congestion control 2003 mechanisms for the control traffic only; no 2004 control for the data traffic. Even so, the 2005 PE could apply value-added functions such as 2006 admission control, policing and shaping of 2007 the L2TP tunnel at the aggregate flows 2008 level, e.g. DiffServ-TE. 2010 Scalability Lack of label stacking ability. 2012 Transport Overhead Minimum overhead is 44-byte (20-byte IP 2013 header + 12-byte UDP header + 8-byte minimum 2014 L2TP header + 4-byte PPP header) to support 2015 L2TP encapsulation 2017 QoS/Traffic Management No built-in QoS and traffic management. 2018 However, one can apply IntServ or DiffServ 2019 to select the preferred transport behavior 2020 for the entire tunnel, i.e. one traffic 2021 class per L2TP tunnel. 2023 7.3. MPLS 2025 Multi-protocol Label Switching [MPLS] is designed to combine Layer 2 2026 switching and Layer 3 routing technology to provide efficient packet 2027 processing and forwarding over a variety of link layer and transport 2028 technologies e.g. ATM, Frame Relay and SONET. 2030 Explicit MP Encap ID No defined standard to identify the 2031 encapsulated multi-protocol PDU. 2033 Transport Integrity No checksum support. 2035 Traffic Engineering Designed with many signaling, routing and 2036 traffic management extensions to support 2037 traffic engineering. 2039 Session Multiplexing Supports session multiplexing via the MPLS 2040 label and the EXP field. 2042 Packet Order Connection-oriented transport with 2043 guaranteed in-sequence delivery. 2045 Tunnel Maintenance MPLS signaling provides the ability to 2046 establish, terminate and monitor the status 2047 of the LSP. 2049 Flow and Congestion Control 2050 MPLS-TE assumes external admission control, 2051 policy and shaping mechanism to provide flow 2052 and congestion control at the aggregate 2053 traffic level. 2055 Scalability Label stacking facilitates scalability. 2057 Transport Overhead Minimum overhead is 4-byte + any MPLS 2058 extension to support multi-protocol 2059 encapsulation and transport. 2061 QoS/Traffic Management MPLS-TE supports QoS and traffic management. 2063 8. Acknowledgments 2065 This document was created by the PWE3 Framework design team. 2067 9. References 2069 9.1. IETF RFCs 2071 [L2TP] W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall, G. 2072 Zorn, B. Palter, "Layer Two Tunneling Protocol (L2TP)", RFC 2073 2661, August 1999. 2075 [RTP] H. Schulzrinne et al, "RTP: A Transport Protocol for Real- 2076 Time Applications", RFC1889, January 1996. 2078 [NTP] D. Mills, "Network Time Protocol Version 3", RFC1305, March 2079 1992. 2081 [MPLS] E. Rosen, "Multiprotocol Label Switching Architecture", 2082 RFC3031, January 2001. 2084 [IP] DARPA, "Internet Protocol", RFC791, September 1981. 2086 9.2. IETF Drafts 2088 [ANAVI] Anavi et al, "TDM over IP" draft-anavi-tdmoip-01.txt, work 2089 in progress, February 2001. 2091 [MALIS] Malis et al, "SONET/SDH Circuit Emulation Service Over MPLS 2092 (CEM) Encapsulation" (draft-malis-sonet-ces-mpls-03.txt), 2093 work in progress, February 2001. 2095 [XIAO] Xiao et al, "Requirements for Pseudo Wire Emulation Edge-to- 2096 Edge (PWE3)" (draft-pwe3-requirements-01.txt), work in 2097 progress, July 2001. 2099 [MARTINI] Martini et al, "Transport of Layer 2 Frames Over MPLS" 2100 (draft-martini-l2circuit-trans-mpls-06.txt), work in 2101 progress, May 2001. 2103 [BONICA] Bonica et al, "Tracing Requirements for Generic Tunnels" 2104 (draft-bonica-tunneltrace-01.txt), work in progress, 2105 February 2001. 2107 [CALLON] Callon et al, "A Framework for Provider Provisioned Virtual 2108 Private Networks" (draft-ietf-ppvpn-framework-00.txt), work 2109 in progress, February 2001. 2111 9.3. ATM Forum 2113 [ATMCES] ATM Forum, "Circuit Emulation Service Interoperability 2114 Specification Version 2.0" (af-vtoa-0078-000), January 1997. 2116 [TM4.0] ATM Forum, "Traffic Management Specification Version 4.0", 2117 (af-tm-0056.000), April, 1996. 2119 [ILMI] ATM Forum, "Integrated Local Management Interface (ILMI) 2120 Specification Version 4.0", (af-ilmi-0065.000), September, 2121 1996. 2123 9.4. Frame Relay Forum 2125 [FRF.1.2] D. Sinicrope, "PVC User-to-Network Interface (UNI) 2126 Implementation Agreement", Frame Relay Forum FRF.1.2, July 2127 2000. 2129 [FRF.5] O'Leary et al, "Frame Relay/ATM PVC Network Interworking 2130 Implementation Agreement", Frame Relay Forum FRF.5, December 2131 20, 1994. 2133 [FRF.13] K. Rehbehn, "Service Level Definitions Implementation 2134 Agreement", Frame Relay Forum FRF.13, August 4, 1998. 2136 9.5. ITU 2138 [Q.933A] ITU, "ISDN Signaling Specifications for Frame Mode Switched 2139 and Permanent Virtual Connections Control and Status 2140 Monitoring" ITU Recommendation Q.933, Annex A, Geneva, 1995. 2142 [I.356] ITU, "B-ISDN ATM Layer Cell Transfer Performance", ITU 2143 Recommendation I.356, To Be Published. 2145 [I.363.1] ITU, "B-ISDN ATM Adaptation Layer specification: Type 1 2146 AAL", Recommendation I.363.1, August, 1996. 2148 [I.363.2] ITU, "B-ISDN ATM Adaptation Layer (AAL) type 2 2149 specification", Recommendation I.363.2, To Be Published. 2151 [I.363.5] ITU, "B-ISDN ATM Adaptation Layer specification: Type 5 2152 AAL", Recommendation I.363.5, August, 1996. 2154 [I.371] ITU, "Traffic Control and Congestion Control in B-ISDN" ITU 2155 Recommendation I.371, To Be Published. 2157 [I.610] ITU, "B-ISDN Operation and Maintenance Principles and 2158 Functions", ITU Recommendation I.610, February, 1999. 2160 [G.811] ITU, "Timing Characteristics of Primary Reference Clocks", 2161 ITU Recommendation G.811, September 1997. 2163 [G.823] "The Control of Jitter and Wander Within Digital Networks 2164 Which Are Based on the 2048 kbit/s Hierarchy", ITU 2165 Recommendation G.823, March 2000. 2167 [G.824] "The Control of Jitter and Wander Within Digital Networks 2168 Which Are Based on the 1544 kbit/s Hierarchy", ITU 2169 Recommendation G.824, March 2000. 2171 9.6. IEEE 2173 [802.1D] IEEE, "ISO/IEC 15802-3:1998,(802.1D, 1998 Edition), 2174 Information technology --Telecommunications and information 2175 exchange between systems --IEEE standard for local and 2176 metropolitan area networks --Common specifications--Media 2177 access control (MAC) Bridges", June, 1998. 2179 [802.1Q] ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and 2180 Metropolitan Area Networks: Virtual Bridged Local Area 2181 Networks", 1998 . 2183 [802.3] IEEE, "ISO/IEC 8802-3: 2000 (E), Information 2184 technology--Telecommunications and information exchange 2185 between systems --Local and metropolitan area networks 2186 --Specific requirements --Part 3: Carrier Sense Multiple 2187 Access with Collision Detection (CSMA/CD) Access Method and 2188 Physical Layer Specifications", 2000. 2190 9.7. ANSI 2192 [T1.403] ANSI, "Network and Customer Installation Interfaces - DS1 2193 Electrical Interfaces", T1.403-1999, May 24, 1999. 2195 [T1.617D] ANSI, "Digital Subscriber System No. 1 DSS1 Signaling 2196 Specification for Frame Relay Bearer Service", ANSI 2197 T1.617-1991 (R1997), Annex D. 2199 9.8. Telcordia 2201 [GR253] Telcordia, "Synchronous Optical Network (SONET) Transport 2202 Systems: Common Generic Criteria" (GR253CORE), Issue 3, 2203 September 2000. 2205 10. Security Considerations 2207 It may be desirable to define methods for ensuring security during 2208 exchange of encapsulation control information at an administrative 2209 boundary of the PSN. 2211 11. Authors' Addresses 2213 Prayson Pate 2214 Overture Networks 2215 P. O. Box 14864 2216 RTP, NC, USA 27709 2217 Email: prayson.pate@overturenetworks.com 2219 XiPeng Xiao 2220 Photuris, Inc. 2221 2025 Stierlin Court 2222 Mountain View, CA 94043 2223 Email: xxiao@photuris.com 2225 Tricci So 2226 Caspian Networks 2227 170 Baytech Dr. 2228 San Jose, CA 95134 2229 E-Mail: tso@caspiannetworks.com 2231 Craig White 2232 Level 3 Communications, LLC. 2233 1025 Eldorado Blvd. 2234 Broomfield, CO, 80021 2235 e-mail: Craig.White@Level3.com 2237 Kireeti Kompella 2238 Juniper Networks, Inc. 2239 1194 N. Mathilda Ave. 2240 Sunnyvale, CA 94089 2241 Email: kireeti@juniper.net 2243 Andrew G. Malis 2244 Vivace Networks, Inc. 2245 2730 Orchard Parkway 2246 San Jose, CA 95134 2247 Email: Andy.Malis@vivacenetworks.com 2249 Thomas K. Johnson 2250 Litchfield Communications 2251 76 Westbury Park Rd. 2252 Watertown, CT 06795 2253 Email: tom_johnson@litchfieldcomm.com 2254 12. Full Copyright Section 2256 Copyright (C) The Internet Society (2000). All Rights Reserved. 2258 This document and translations of it may be copied and furnished to 2259 others, and derivative works that comment on or otherwise explain it 2260 or assist in its implementation may be prepared, copied, published 2261 and distributed, in whole or in part, without restriction of any 2262 kind, provided that the above copyright notice and this paragraph are 2263 included on all such copies and derivative works. However, this 2264 document itself may not be modified in any way, such as by removing 2265 the copyright notice or references to the Internet Society or other 2266 Internet organizations, except as needed for the purpose of 2267 developing Internet standards in which case the procedures for 2268 copyrights defined in the Internet Standards process must be 2269 followed, or as required to translate it into languages other than 2270 English. 2272 The limited permissions granted above are perpetual and will not be 2273 revoked by the Internet Society or its successors or assigns. 2275 This document and the information contained herein is provided on an 2276 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2277 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2278 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2279 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2280 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.