idnits 2.17.1 draft-ietf-iporpr-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 46 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (June 2001) is 8344 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '6' is defined on line 667, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1142 (ref. '1') (Obsoleted by RFC 7142) ** Obsolete normative reference: RFC 2178 (ref. '3') (Obsoleted by RFC 2328) -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Albert Herrera 2 Internet Draft Lantern Communications 3 draft-ietf-iporpr-framework-01.txt 4 Expiration Date: December 2001 Russ White 5 Cisco Systems 7 Pankaj K. Jha 8 Cypress Semiconductor 10 Raj Sharma 11 Sanjay Agrawal 12 Prasad Jogalekar 13 Arun Sastry 14 Luminous Networks 16 Khaled Amer 17 AmerNet 19 June 2001 21 A Framework for IP over Resilient Packet Rings 22 24 Status of this Memo 26 This document is an Internet-Draft and is in full conformance with 27 all provisions of Section 10 of RFC2026. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that other 31 groups may also distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Herrera, et al. Expires December 2001 [Page 1] 45 Abstract 47 This document discusses technical issues and requirements of running 48 IP over Resilient Packet Rings. It is the intent of this document to 49 produce a coherent description of all significant approaches, which 50 were and are being considered by the IPORPR working group. Selections 51 of specific approaches, making choices regarding engineering 52 tradeoffs, and detailed protocol specification, are outside of the 53 scope of this framework document. 55 Specification of Requirements 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC 2119. 61 Table of Contents 63 1 Introduction ........................................... 3 64 1.1 Terminology ........................................... 3 65 1.2 Overview of IEEE 802.17 RPR ............................ 3 67 2 IPORPR Objectives........................................ 5 69 3 Motivation for IPORPR .................................. 5 70 3.1 Benefits Related to Traditional Broadcast Media Approach. 6 71 3.2 Benefits Related to a Client/Service Interface to RPR.... 6 72 3.3 Benefits Related to Enhanced L3 Awareness .............. 7 74 4 IPORPR Input and Proposals to 802.17 RPRWG .............. 9 75 4.1 No Changes to IP in a L2-Broadcast-Media Mode ........... 9 76 4.2 Support for a Service Interface Capability ............. 9 77 4.2.1 Proposed Operations .................................. 10 78 4.2.2 Granularity of Provisioned BW/Path/Tunnel/Circuit .... 11 79 4.3 Support for Enhanced Layer3 Operation ................ 11 80 4.3.1 Discovering Logical Adjacencies on the Ring .......... 11 81 4.3.2 Ring Direction Indication ............................ 12 82 4.3.3 Fault Interaction .................................... 12 83 4.3.4 Traffic Engineering .................................. 12 84 4.4 Network Management Support ............................. 13 86 5 Acknowledgements ....................................... 13 87 6 Security ............................................... 13 88 7 Full Copyright Statement ............................... 14 89 8 References ............................................. 14 90 9 Author's Addresses ..................................... 15 92 Appendix A: Logical Adjacency TLV Format and Processes ......... 16 94 Herrera, et al. Expires December 2001 [Page 2] 95 1. Introduction 97 This document takes into consideration the parallel efforts that are 98 progressing within the IEEE and IETF. IEEE's 802.17 RPRWG is expected 99 to develop an RPR (Resilient Packet Rings) MAC standard that 100 optimizes packet transport over rings on LAN, MAN and WAN topologies. 101 The primary goal of IETF's IPORPR WG is to articulate a set of 102 features that integrates the RPR MAC functions as defined by the 103 802.17 RPRWG with network layer routing. 105 This document is based on current 802.17 RPRWG objectives and 106 assumptions, which are by no means final. 108 1.1 Terminology 110 - Link Layer or Layer 2 or L2: Refer to the data-link layer such as 111 IEEE 802.3 / Ethernet and, in the case of this document, IEEE 112 802.17/RPR. 114 - Layer 2 or L2 devices: Refer to devices that only implement Layer 2 115 functionality. 117 - Layer 3 or L3: Layer 3 of the ISO 7 layer model and the use of the 118 Internet Protocol (IP) at this layer. 120 - Layer 3 or L3 devices: Refer to devices that implement Layer 3 121 functionality. 123 - The reader is assumed to be familiar with the terminology as 124 defined in [1] [2] [3] [4] [5]. 126 1.2 Overview of IEEE 802.17/RPR 128 Traditional metro and core networks were designed and optimized for 129 voice and video using the SONET/SDH circuit switch layer. Today's 130 dominant traffic sources are data applications that drive bandwidth 131 demands in both the MAN and WAN. Carrying data traffic on traditional 132 circuit switched networks has proven to be inefficient, complex and 133 expensive. 135 The IEEE 802.17 Working Group was established to formulate a new 136 Resilient Packet Rings (RPR) MAC layer standard. RPR is designed to 137 be a packet switched technology optimized for data traffic while 138 maintaining carrier class operational attributes previously available 139 only through circuit switch services. 141 Herrera, et al. Expires December 2001 [Page 3] 142 Some objectives adopted by the 802.17 RPRWG include: 144 - Support for a dual counter-rotating ring topology 145 - Support for destination stripping of unicast traffic 146 - Support for protection switching in less than 50ms 147 - Support for data rates of (at least) 1 Gb/s to 10Gb/s 148 - Support for a MAC that is both PHY and payload agnostic 149 - Support for a fully distributed access method (no master node) 150 - Support for multi-vendor interoperability at the ring level 151 - Support for multicast traffic 152 - Support for managed objects or management "hooks" required for 153 efficient operational control of the network. 155 These objectives define a network topology made up of closed-loop, 156 point to point, spans with the MAC layer creating the resulting 157 logical ring topology. At the physical layer, RPR looks like a set of 158 point-to-point spans while at the datalink layer it appears to be a 159 broadcast media LAN (equivalent to Ethernet, for instance). The dual 160 logical rings created are counter-rotating, carrying both control and 161 data packets. Packets are destination stripped for efficient 162 bandwidth utilization and prioritized for appropriate treatment 163 during protection situations. Protection mechanisms will meet or 164 better the SONET's 50ms service guarantees without the need for 165 dedicated or reserved bandwidth for redundancy. Data rates are 166 defined at 1 Gb/s to 10Gb/s but do not preclude support for lower or 167 higher rates in the future. 169 These are initial objectives passed by the 802.17 WG with more to 170 follow. IPORPR, further described in section 2.0, will build upon 171 this set of features. 173 This initial set of objectives provides RPR with the following key 174 attributes. 176 Bandwidth Efficiency: 178 Unlike traditional SONET networks that require as much as 50% of ring 179 bandwidth for redundancy, RPR utilizes both dual counter rotating 180 rings for control and data traffic while still maintaining SONET APS- 181 like protection mechanisms. Spatial reuse is achieved by allowing a 182 bi-directional flow of traffic on ring spans between source and 183 destination nodes. The destination node strips unicast packets from 184 the ring. When a packet is "stripped" from the ring, it no longer 185 consumes bandwidth on the ring, but frees up downstream spans to be 186 utilized by other packets. 188 Herrera, et al. Expires December 2001 [Page 4] 189 Protection: 191 RPR's objective is to provide 50ms service protection similar to 192 SONET APS. Approaches under consideration are to wrap and/or steer 193 traffic away from the fault. When 'wrapping', nodes adjacent to the 194 fault will 'wrap' traffic around onto the other ring (i.e. inner ring 195 traffic to outer) allowing flows to maintain connectivity to the 196 destination node by way of a long path. 'Steering' will actually 197 divert flows to the destination via the long path. A combination of 198 both is also an option where nodes beside the fault will first 'wrap' 199 then steer at their convenience. 201 This protection feature will be available while fully utilizing both 202 counter-rotating physical fibers. Traffic priorities ensure 203 appropriate handling of high priority vs. best effort traffic during 204 fault situations. 206 Simplified Service Provisioning: 208 One RPR objectives is for a distributed access method. This feature 209 together with the fast protection and automatic re-establishment of 210 services, provide for plug-and-play mechanisms for quick insertion 211 and removal of nodes. 213 RPR is also designed as a packet switched technology utilizing shared 214 bandwidth within the rings, with nodes aware of available ring 215 capacities. The simplicity becomes evident on full-mesh connectivity 216 requirements where traditional circuit-based models require O(n2) 217 point-to-point connections versus RPR's single service connection to 218 the ring. 220 2. IPORPR Objectives 222 The primary goal of the IPORPR Working Group is to articulate a set 223 of features and functionality that will allow IP to integrate 224 smoothly with the RPR MAC functions as described in Section 1.2. This 225 will be presented as input to IEEE's 802.17 RPRWG for consideration. 226 The intent is to align the needs of the Internet and IP with the 227 emerging 802.17 standard with the hope that the 802.17 RPRWG will 228 make design choices that take these requirements into consideration 229 and in some instances, avoid duplication of efforts. 231 3. Motivation for IPORPR 233 Network layer routing can treat these RPR rings as a broadcast 234 capable LAN media similar to Ethernet without requiring any change to 235 current L3 protocols. With minimal change, it could also leverage 236 RPR's unique features, such as dual-counter-rotating rings, 237 destination stripping (which effectively provide two possible paths 238 from a source node to a destination node) or 50ms protection 239 switching (capable of masking any single physical fault). 241 Herrera, et al. Expires December 2001 [Page 5] 242 There are three basic approaches to L2/L3 interaction presented in 243 this document (further described in the following sections): 245 - L3 view of an RPR ring as a traditional broadcast media 246 - A L3 service interface to an RPR ring for specific 247 resource/services requests 248 - Enhance L3 awareness and interaction with an RPR ring. 250 Introducing additional L2/L3 interaction will provide increased 251 ability to better utilize ring resources and increase efficiency and 252 scalability at Layer 3. 254 The following are projected benefits related to IPORPR. 256 3.1 Benefits Related to Traditional Broadcast Media Approach 258 In an approach where L3 treats an RPR Ring as a traditional data 259 link, broadcast media (e.g. Ethernet), L3 will rely on L2 to provide 260 the benefits of the underlying features such as protection 261 mechanisms, congestion control and bandwidth management within each 262 RPR ring domain. 264 This is the simplest approach to L2/L3 interaction and requires no 265 change whatsoever to existing L3 protocols. 267 3.2 Benefits Related to a Client/Service Interface to RPR 269 RPR rings include a distributed access management capability that 270 allows rapid establishment and reconfiguration of flows and/or 271 connections, reducing provisioning times and effectively lowering 272 costs while providing the means to set and guarantee SLAs and QoS 273 configured on either a per-flow and/or connection basis. The 274 projected new services for RPR rings are bandwidth on demand, point 275 and click establishments of circuits/paths and VLANs and/or VPNs. 277 A standardized interface between RPR and the service layers such as 278 IP will allow end-to-end internetworking of paths and flows through 279 these rings and will provide the benefits of RPR end-to-end even if 280 other networks are involved (i.e. meshes). 282 This service interface will allow clients to the RPR ring to signal 283 parameters (i.e. SLA constraints, bandwidth requirements, etc.) to L2 284 for specific path selection or other L2 behavioral characteristics. 285 The signaling and routing interface between the client (IP and 286 others) and the RPR ring is similar to traditional User-Network 287 Interface (UNI). 289 This allows either a dynamic and/or static set of capabilities for 290 service provisioning without closely coupling the underlying RPR ring 291 operations to the upper layers. 293 Herrera, et al. Expires December 2001 [Page 6] 294 This interface can support a range of clients from individual 295 customers to lower tier ISPs connected to a carrier's carrier for 296 dynamic provisioning of services or the service provider's management 297 console for static establishment of services. 299 3.3 Benefits Related to Enhanced L3 Awareness 301 Enhanced L3 awareness of the underlying physical topology will allow 302 greater L3 controls of certain ring operations/behaviour such as 303 choice of ring direction, alternate fault response, traffic 304 engineering and related QoS metrics. 306 Note that this document does not address issues related to enhanced 307 Layer 3 awareness across bridged, multi-ring domains. In topologies 308 such as these, it might be best for Layer 3 to simply treat these as 309 simple broadcast domains. 311 The following are related L3 components that can be enhanced when 312 running IP over RPR rings. 314 Cost Metrics Awareness: 316 At the MAC layer, RPR may implement its own topology discovery 317 mechanism within a single set of dual-ring implementation. This may 318 involve tracking source and destination MAC addresses and utilizing 319 simple metrics, such as number of hops, to determine the shortest 320 path and most efficient ring direction for delivery of unicast 321 packets. 323 For instance, in the network depicted below, the cost from node A to 324 node C would be 1 hop across the directly connected side of the ring, 325 while it would be two hops through node B. 327 /----(20)------A 328 / | 329 C (5) 330 \ | 331 \----(5)-------B 333 However, using L3 associated costs for links between the nodes (based 334 on physical distance or some other link trait, for instance), the 335 path through node B is shorter. 337 Communicating the preferred ring direction to L2, based on layer 3 338 metrics can optimize packet delivery - especially in topologies with 339 dramatic differences in node distances and costs. 341 Herrera, et al. Expires December 2001 [Page 7] 342 Adjacency and Fault Awareness: 344 Given RPR's destination stripping ability, and once fault 345 notification is enabled between Layer 2 and 3, it would be beneficial 346 for Layer 3 to be aware of directly adjacent neighbors for route re- 347 calculation during fault situations. 349 Within a single ring domain, the benefits of adjacency awareness 350 might not be obvious since the underlying RPR mechanisms will self- 351 heal and send flows efficiently around or away from faults to 352 maintain connectivity. However, L3 route recalculation might be 353 necessary to fully reflect the changed topology during these events 354 especially when the user deploys a mix of ring and mesh topologies. 355 This will allow a recalculation of paths based on established cost 356 metrics. 358 For instance, in the network depicted below, a ring made up of nodes 359 A, B, C and D is bisected by a P2P link between D and B with a cost 360 of (5). Under normal ring operations, C will reach B in a counter- 361 clockwise direction via a single span with a cost of (5). Should a 362 fault occur on this span between C and B, C will reach B via D 363 skipping A altogether due to an expensive span cost when traversing A 364 on a clockwise ring direction. 366 (5)-------A-----(20) 367 | | 368 D-------(5)------B 369 | | 370 (5)-------C---X--(5) 372 Notifying L3 of fault situations from the lower layers will allow 373 swifter response from L3 should this be required by the user. Fault 374 situations that L3 should be aware of are those that would cause ring 375 traffic to be wrapped or redirected away from the fault. Other minor 376 fault situations, where ring operations continue to function, might 377 not have to be communicated to L3. 379 TE/Explicit Routing/QoS Routing Support: 381 Although RPR might incorporate its own topology discovery, bandwidth 382 management and congestion/flow control mechanisms at L2, there might 383 be instances wherein L3 would prefer to override these. 385 MPLS, used for traffic engineering, offers several benefits within an 386 RPR-ring topology. One benefit is the capability to establish 387 explicit switched paths that are not constrained by any of RPR's 388 forwarding paradigms. The MPLS preferred path along the ring could be 389 the long-path towards a destination node. Another benefit is the 390 capability to associate attributes to these traffic flows and to 391 administer these flows across diverse topologies (combination of 392 meshes and rings). This same mechanisms will enable L3 per flow QoS 393 treatment in which the path chosen for a particular stream is chosen 394 in response to the QoS constraints. 396 Herrera, et al. Expires December 2001 [Page 8] 397 4. IPORPR Input and Proposals to 802.17 RPRWG 399 The IPORPR Working Group was chartered by the IESG to produce a 400 requirements and framework document, which can be used as input to 401 the IEEE 802.17 RPRWG. The intent is to help the RPRWG formulate its 402 requirements. Areas of particular interest to the IPORPR WG are: 403 Layer 2 to Layer 3 interaction in: alarm notification; fast 404 restoration; fast convergence; traffic engineering and quality of 405 service issues. 407 The primary requirement set forward by IPORPR is that the IEEE 802.17 408 WG makes design decisions that will have the least impact and require 409 the least amount of change to IP. 411 The following are the proposed requirements for L2/L3 interaction. 413 4.1 No Changes to IP in a L2-Broadcast-Media Mode 415 The first and foremost requirement for 802.17 is to allow IP to 416 operate without any changes, whatsoever, when treating RPR rings as a 417 traditional L2 broadcast media. This approach should not be any 418 different from how IP operates today over other data link layers such 419 as Ethernet. This will allow existing protocols and design constructs 420 to apply unchanged. 422 4.2 Support for a Service Interface Capability 424 A 'service interface' can be thought of as a User-Network Interface 425 (UNI). A connection, in a UNI sense, is defined by its demarcation 426 from the ingress node to egress node. These can be within the same 427 ring or might span other rings or meshes. The behaviors of these 428 pairings are defined by their connection attributes. A standardized 429 set of parameters is required for the edge-facing interfaces. This 430 will include service requirements and attributes during normal ring 431 operations and during fault situations. Specifics for these 432 parameters are not discussed in this current framework but should be 433 developed as the 802.17 standards evolve and as more detailed 434 features and behaviors are firmed up. 436 There are two approaches in terms of request handoffs from a service 437 interface. 439 One approach is to handoff requests to L2 and use L2 capabilities, 440 such as topology discovery, path selection and bandwidth accounting, 441 to service requests from the client interface. RPR's ring operations 442 should be capable of satisfying these requests in terms of contracts 443 associated with SLAs. 445 Herrera, et al. Expires December 2001 [Page 9] 446 The other approach is to allow L3 intelligence to meet these 447 requests. In cases where enhanced L3 awareness is enabled for traffic 448 engineering, path establishment, bandwidth accounting, QoS and 449 associated signaling, service parameters can be handed over to L3. 450 This approach will accommodate requirements for extending any 451 existing L3 provisioning and signaling models (i.e. on mesh networks) 452 to and through RPR ring topologies. 454 Both approaches should be supported. 456 4.2.1 Proposed Operations 458 A client upon ingress to the RPR ring may request: 460 - a new connection subject to policy 461 - a tear-down of an existing connection 462 - attribute modifications to an existing connection based on policy 463 - attribute queries on an existing connection 464 - status queries of issued requests 466 Admission control in terms of accepting or rejecting requests depends 467 on the underlying provisioning and signaling capabilities. Local node 468 policy will dictate when connections may be established and whether 469 these are dynamically established or administratively controlled. 470 Parameters and associated mechanisms are required to validate 471 interoperable capabilities at the ingress and egress ports of a 472 requested connection. Neither the connection setup mechanism nor the 473 method for identifying flows is addressed in this document. 475 Bounded delay guarantees require that every RPR node in the 476 connection path supports a guaranteed service feature whether within 477 the L2 operations itself and/or via L3 enhancements, resource 478 accounting and policy enforcements. Each RPR node accepting a request 479 for service must ensure that adequate bandwidth and packet processing 480 resources are available to handle the request as specified in the 481 client's request parameters / Traffic Specifications. This may be 482 implemented through active admission control based on resource 483 availability such as link bandwidth, port buffer space, forwarding 484 engine capacity or transit traffic treatments. The assumption is that 485 802.17 will provide the appropriate architecture to meet stringent 486 delay and jitter guarantees whether through appropriate queuing 487 mechanisms, media access management or transit traffic mechanisms. 489 In cases where the RPR node detects a failure on the ingress physical 490 port, or if the ingress port is administratively disabled, the 491 corresponding service connection, related mappings and reservations 492 may be withdrawn. Payload synchronization and maintenance alarm 493 requirements are outside the scope of this document. 495 4.2.2 Granularity of Provisioned Bandwidth/Path/Tunnel/Circuit 497 As stated on the objectives, RPR rings will support at a minimum, 498 data rates, on the ring, of 1Gb/s to 10Gb/s with even higher rates 499 for consideration within 802.17 in the future. At the ingress service 500 interface, an upper limit equivalent to the fastest link on the ring 501 should be allowed, as well as lower granularities such as 1Gb/s, 502 10/100mb/s, 128kb/s, 56kb/s, etc. 504 4.3 Support for Enhanced Layer3 Operation 506 Upper layer protocols will require various interaction points with 507 RPR rings to take effective advantage of the available bandwidth (in 508 both directions) through the ring. Generally, these interaction 509 points will fall into two categories: Informing the data link layer 510 of ring direction choices made by Layer 3 protocols for each next hop 511 along the ring, and informing the Layer 3 protocols of the ring 512 topology. 514 The following are technical approaches for consideration: 516 4.3.1 Discovering Logical Adjacencies on the Ring 518 IS-IS and OSPF require knowledge of all neighbors on a ring with the 519 additional information of which neighbor is directly connected 520 upstream and directly connected downstream. Since all devices 521 attached to a ring may not be running layer three protocols, simply 522 using the physical topology discovered by the data link layer isn't 523 an effective way to discover all layer three topology information. 524 Instead, it will be more effective for RPR to provide an opaque 525 transport through which routing protocols can determine which 526 neighbors are logically attached upstream and downstream. 528 To this end, the RPR data link layer should be able to carry 'opaque 529 data' TLV's (Type/Length/Value) between nodes, accepting data from 530 upper layer protocols, and passing this information back up the stack 531 on adjacent nodes only (Refer to Appendix A: Logical Adjacency TLV 532 Format and Processes). 534 Through this process, devices running layer 3 protocols will discover 535 its directly adjacent downstream and directly adjacent upstream 536 neighbors. 538 NOTE: This is one implementation possibility used to explain the 539 behavior; this document is not intended to restrict or dictate the 540 correct implementation to achieve this behavior. This could, for 541 instance, be implemented using multicast between the nodes, which 542 layer two could then compare to the physical topology discovered 543 through other means, passing only the information about 'logical 544 neighbors' up to layer 3, or some other mechanism. 546 4.3.2 Ring Direction Indication 548 A mechanism MUST exist for Layer 3 to override any indication by 549 Layer 2 as to the direction to be followed on the ring to reach any 550 of its nodes. The two possible directions are "upstream" and 551 "downstream". Administrative policies and/or traffic engineering 552 parameters will influence layer 3 decisions. 554 If Layer 3 does not indicate one of these directions, then Layer 2 555 SHOULD use its own methods to determine it. 557 Should Layer 2 determine the ring direction, there might be instances 558 where the direction taken by RPR be explicitly indicated to Layer 3. 559 These are instances where strict latency and jitter requirements are 560 to be met and ring direction decisions will require indications from 561 Layer 2. 563 4.3.3 Fault Interaction 565 If a device on the ring or a link between two nodes on the ring 566 fails, the ring will wrap or steer traffic away from the fault. 567 During these fault situations, nodes adjacent to the fault might want 568 to perform route re-computation and advertise a single ring adjacency 569 in their LSP. A signal MUST be provided to the layer 3 protocols on 570 the attached nodes indicating the loss of a logical adjacency. Layer 571 2 MUST NOT provide information about the newly reachable neighbor 572 through the wrapped or re-directed ring, as this could cause layer 3 573 to be unable to properly converge on the new topology. 575 In cases where a node failure occurs, where a particular device 576 leaves the ring but maintains transit paths and ring connectivity in 577 place, normal RPR ring operations are expected to proceed as normal. 578 Any fault interaction is expected to be resolved at a higher layer 579 where procedures are in place to react a lost destination nodes or 580 adjacencies (e.g. hellos, keepalives, topology refresh, etc.). 582 4.3.4 Traffic Engineering 584 To take full advantage of RPR, TE capabilities should be made 585 available to manage bandwidth on both inner and outer rings. 587 Sometimes it is preferred to force a packet to follow an explicitly 588 chosen route different from the path chosen by a dynamic routing 589 protocol or different from the shortest path chosen by RPR. This 590 implies the capability to determine the ring direction a particular 591 flow or tunnel will take (long path or short path) and the capability 592 to establish an explicitly routed path from ingress to egress. 594 RPR should be able to meet the SLA constraints of established flows 595 that originate from outside the ring whether from another ring or 596 from a mesh topology. This implies the capability to apply resource 597 reservations along a chosen path and the capability to recognize 598 precedence and class of service parameters for applicable discard or 599 scheduling mechanisms. 601 In terms of MPLS support, different approaches for label stack 602 encoding, to enable forwarding of labeled packets encapsulated within 603 RPR headers, can be referenced in [5]. 605 This document does not suggest use of a single label distribution 606 protocol. Please refer to [4] for options and implications. 608 This document does not cover interaction between RPR protection 609 switching and MPLS based fault recovery mechanisms. 611 4.4 Network Management Support 613 RPR MUST support operations, administration, and maintenance 614 facilities that are at least as extensive as those supported in 615 current IP networks. Current network management and diagnostic tools 616 SHOULD continue to work in order to provide some backward 617 compatibility. 619 5. Acknowledgments 621 The ideas and text in this document have been collected from a number 622 of sources and comments received. We would like to thank John 623 Coulter, Kshitij Kumar, Alvaro Retana, Don Slice, Liem Nguyen, 624 Thierry Paiement, Jason Fan, Vinay Bannai for their inputs and ideas. 626 6. Security 628 Security in a network using IPORPR should be relatively similar to 629 security in a normal IP network. The route filtering and packet 630 filtering features are unchanged. 632 7. Full Copyright Statement 634 "Copyright (C) The Internet Society. All Rights Reserved. This 635 document and translations of it may be copied and furnished to 636 others, and derivative works that comment on or otherwise explain it 637 or assist in its implementation may be prepared, copied, published 638 and distributed, in whole or in part, without restriction of any 639 kind, provided that the above copyright notice and this paragraph are 640 included on all such copies and derivative works. However, this 641 document itself may not be modified in any way, such as by removing 642 the copyright notice or references to the Internet Society or other 643 Internet organizations, except as needed for the purpose of 644 developing Internet standards in which case the procedures for 645 copyrights defined in the Internet Standards process must be 646 followed, or as required to translate it into." 648 8. References 650 [1] ISO 10589, "Intermediate System to Intermediate System Intra- 651 Domain Routing Exchange Protocol for use in Conjunction with 652 the Protocol for Providing the Connectionless-mode Network 653 Service (ISO 8473)" [Also republished as RFC 1142] 655 [2] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual 656 environments", R. W. Callon, Dec. 1990 658 [3] RFC 2178, "OSPF Version 2", J. Moy. July 1997 660 [4] RFC 3031, "Multiprotocol Label Switching Architecture", E. 661 Rosen, A. Viswanathan, R. Callon, January 2001. 663 [5] RFC 3032, "MPLS Label Stack Encoding", Rosen, E., Rekhter, Y., 664 Tappan, D., Fedorkow, G., Farinacci, D. and A. Conta, 665 January 2001. 667 [6] IEEE 802.17 RPR PAR and 5 Criteria, http://www.ieee802.org/17, 668 November 2000. 670 9. Author's Addresses 672 Albert Herrera 673 Lantern Communications 674 2000-1642 Merivale Road, 675 Ottawa, ON K2G 4A1 676 Phone: 613-727-7112 677 Email: aherrera@lanterncom.com 679 Russ White 680 Cisco Systems, Inc. 681 7025 Kit Creek Road 682 Research Triangle Park, NC 683 Phone: 919 392-3139 684 Email: ruwhite@cisco.com 686 Pankaj K Jha 687 Cypress Semiconductor 688 3901 N First Street 689 San Jose, CA 95134 690 Phone: 408 432 7091 691 pkj@cypress.com 693 Raj Sharma (raj) 694 Sanjay Agrawal (sanjay) 695 Prasad Jogalekar (prasad) 696 Arun Sastry 697 (arun@luminousnetworks.com) 698 Luminous Networks 699 10460 Bubb Road 700 Cupertino, CA 95014 701 Tel: 408-342-6400 703 Khaled Amer 704 AmerNet 705 Email: khaledamer@usa.net 707 Appendix A: Logical Adjacency TLV Format and Processes 709 IS-IS and OSPF require knowledge of all neighbors on a ring with the 710 additional information of which neighbor is directly connected 711 upstream and directly connected downstream. To this end, the RPR data 712 link layer should be able to carry 'opaque data' TLV's 713 (Type/Length/Value) between nodes, accepting data from upper layer 714 protocols, and passing this information back up the stack on adjacent 715 nodes only. 717 So, for instance, in this small sample ring, one possible 718 implementation of this functionality would be: 720 B 721 / \ 722 A C 723 \ / 724 D 726 Assume that A, B, and C are running some layer three protocol, while 727 D is not. A needs to know which devices on the ring are possible next 728 hops upstream and downstream. To facilitate this: 730 - A, B, and C will inject information into a Logical Adjacency TLV 731 (LAT) which will be carried by the RPR data link layer both upstream 732 and downstream. 734 - When A receives B's LAT, the RPR data link processes will determine 735 which protocol stack to pass the opaque information within the TLV 736 to, and pass it up the stack with an indication of which direction is 737 used to reach this adjacent device. 739 - When D receives C's LAT, it will discover that it has no layer 740 three protocol running, so it will simply forward the LAT on to A. 742 - When A receives C's LAT, the RPR data link processes will again 743 determine which protocol to forward the opaque portion of the data 744 to, and pass it up the stack with an indication of which ring 745 direction is used to reach this adjacent device. 747 Through this process, A will discover that it's directly adjacent 748 downstream (clockwise) neighbor is B, while it's directly adjacent 749 upstream (counter clockwise) neighbor is C. A's routing processes can 750 use this information, in conjunction with information learned at 751 layer three, to make optimal routing decisions through the ring. 753 Logical Adjacency TLV Format 755 ------------------------------------------------------ 756 | src mac| id_number | id_type | id_len | id | ... 757 ------------------------------------------------------ 759 o src mac: The MAC address of the source ring node 761 o id_number (1 byte): The number of this identifier within the packet 763 o id_type (1 byte): described below 765 o id_len (2 bytes): length of the opaque information contained in 766 the id section 768 o id: The actual opaque information provided by the layer 3 769 protocol, and passed to the receiving device's layer 3 770 protocol. 772 ID Type Field 774 While the information contained within the logical adjacency TLV's is 775 opaque to the RPR data link layer, the TLV's themselves need to be 776 identifiable in some way so the layer 3 protocol on one device 777 receives the correct TLV from the layer 3 protocols on connected 778 devices. To this end, the TLV should be encoded with a protocol 779 identifier of some type. 781 Three protocol identifiers are defined here, and others can be 782 identified as needed in the future. 784 o OSPF: 1 785 o IS-IS: 2 786 o BGP: 3 787 o EIGRP: 4