idnits 2.17.1 draft-rfced-info-katsube-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. 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. ** There are 10 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance of lines with control characters in the document. == There is 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 408 has weird spacing: '... subnet subn...' -- 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. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'KAT95' is mentioned on line 118, but not defined == Unused Reference: 'NHRP09' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'RFC1483' is defined on line 813, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-ietf-ipatm-ipmc is -11, but you're referring to -12. == Outdated reference: A later version (-15) exists of draft-ietf-rsvp-spec-13 == Outdated reference: A later version (-14) exists of draft-ietf-rolc-nhrp-09 ** Obsolete normative reference: RFC 1483 (Obsoleted by RFC 2684) ** Obsolete normative reference: RFC 1577 (Obsoleted by RFC 2225) Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Expires: April 1997 Internet-Draft 4 Category: Informational Yasuhiro Katsube 5 Ken-ichi Nagami 6 Hiroshi Esaki 7 (Toshiba R&D Center) 9 Router Architecture Extensions for ATM : Overview 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstract.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 This memo describes a new internetworking architecture which makes 33 better use of the property of ATM. IP datagrams are transferred 34 along hop-by-hop path via routers, but datagram assembly/disassembly 35 and IP header processing are not necessarily carried out at 36 individual routers in the proposed architecture. A concept of "Cell 37 Switch Router (CSR)" is introduced as a new internetworking 38 equipment, which has ATM cell switching capabilities in addition to 39 conventional IP datagram forwarding. Proposed architecture can 40 provide applications with high-throughput and low-latency ATM pipes 41 while retaining current router-based internetworking concept. It 42 also provides applications with specific QoS/bandwidth by 43 cooperating with internetworking level resource reservation protocols 44 such as RSVP. 46 Katsube, et al. Expires April 1997 [Page 1] 47 1. Introduction 49 The Internet is growing both in its size and its traffic volume. 50 In addition, recent applications often require guaranteed bandwidth 51 and QoS rather than best effort. Such changes make the current 52 hop-by-hop datagram forwarding paradigm inadequate, then accelerate 53 investigations on new internetworking architectures. 55 Roughly two distinct approaches can be seen as possible solutions; 56 the use of ATM to convey IP datagrams, and the revision of IP to 57 support flow concept and resource reservation. Integration or 58 interworking of these approaches will be necessary to provide end 59 hosts with high throughput and QoS guaranteed internetworking 60 services over any datalink platforms as well as ATM. 62 New internetworking architecture proposed in this draft is based on 63 "Cell Switch Router (CSR)" which has the following properties. 65 - It makes the best use of ATM's property while retaining current 66 router-based internetworking and routing architecture. 68 - It takes into account interoperability with future IP that 69 supports flow concept and resource reservations. 71 Section 2 of this draft explains background and motivations of our 72 proposal. Section 3 describes an overview of the proposed 73 internetworking architecture and its several remarkable features. 74 Section 4 discusses control architectures for CSR, which will need to 75 be further investigated. 77 2. Background and Motivation 79 It is considered that the current hop-by-hop best effort datagram 80 forwarding paradigm will not be adequate to support future large 81 scale Internet which accommodates huge amount of traffic with certain 82 QoS requirements. Two major schools of investigations can be seen in 83 IETF whose main purpose is to improve ability of the Internet with 84 regard to its throughput and QoS. One is to utilize ATM technology 85 as much as possible, and the other is to introduce the concept of 86 resource reservation and flow into IP. 88 1) Utilization of ATM 90 Although basic properties of ATM; necessity of connection setup, 91 necessity of traffic contract, etc.; is not necessarily suited to 92 conventional IP datagram transmission, its excellent throughput and 93 delay characteristics let us to investigate the realization of IP 94 datagram transmission over ATM. 96 Katsube, et al. Expires April 1997 [Page 2] 97 A typical internetworking architecture is the "Classical IP Model" 98 [RFC1577]. This model allows direct ATM connectivities only between 99 nodes that share the same IP address prefix. IP datagrams should 100 traverse routers whenever they go beyond IP subnet boundaries even 101 though their source and destination are accommodated in the same ATM 102 cloud. Although an ATMARP is introduced which is not based on legacy 103 datalink broadcast but on centralized ATMARP servers, this model does 104 not require drastic changes to the legacy internetworking 105 architectures with regard to the IP datagram forwarding process. 106 This model still has problems of limited throughput and large 107 latency, compared with the ability of ATM, due to IP header 108 processing at every router. It will become more critical when 109 multimedia applications that require much larger bandwidth and lower 110 latency become dominant in the near future. 112 Another internetworking architecture is "NHRP (Next Hop Resolution 113 Protocol) Model"[NHRP09]. This model aims at resolving throughput and 114 latency problems in the Classical IP Model and making the best use of 115 ATM. ATM connections can be directly established from an ingress 116 point to an egress point of an ATM cloud even when they do not share 117 the same IP address prefix. In order to enable it, the Next Hop 118 Server[KAT95] is introduced which can find an egress point of the ATM 119 cloud nearest to the given destination and resolves its ATM address. 120 A sort of query/response protocols between the server(s) and clients 121 and possibly server and server are specified. After the ATM address 122 of a desired egress point is resolved, the client establishes a 123 direct ATM connection to that point through ATM signaling 124 procedures[ATM3.1]. Once a direct ATM connection has been set up 125 through this procedure, IP datagrams do not have to experience 126 hop-by-hop IP processing but can be transmitted over the direct ATM 127 connection. Therefore, high throughput and low latency 128 communications become possible even if they go beyond IP subnet 129 boundaries. It should be noted that the provision of such direct ATM 130 connections does not mean disappearance of legacy routers which 131 interconnect distinct ATM-based IP subnets. For example, hop-by-hop 132 IP datagram forwarding function would still be required in the 133 following cases: 135 - When you want to transmit IP datagrams before direct ATM connection 136 from an ingress point to an egress point of the ATM cloud is 137 established 139 - When you neither require a certain QoS nor transmit large amount of 140 IP datagrams for some communication 142 - When the direct ATM connection is not allowed by security or policy 143 reasons 145 Katsube, et al. Expires April 1997 [Page 3] 146 2) IP level resource reservation and flow support 148 Apart from investigation on specific datalink technology such as ATM, 149 resource reservation technologies for desired IP level flows have 150 been studied and are still under discussion. Their typical examples 151 are RSVP[RSVP13] and STII[RFC1819]. 153 RSVP itself is not a connection oriented technology since datagrams 154 can be transmitted regardless of the result of the resource 155 reservation process. After a resource reservation process from a 156 receiver (or receivers) to a sender (or senders) is successfully 157 completed, RSVP-capable routers along the path of the flow reserve 158 their resources for datagram forwarding according to the requested 159 flow spec. 161 STII is regarded as a connection oriented IP which requires 162 connection setup process from a sender to a receiver (or receivers) 163 before transmitting datagrams. STII-capable routers along the path 164 of the requested connection reserve their resources for datagram 165 forwarding according to the flow spec. 167 Neither RSVP nor STII restrict underlying datalink networks since 168 their primary purpose is to let routers provide each IP flow with 169 desired forwarding quality (by controlling their datagram scheduling 170 rules). Since various datalink networks will coexist as well as ATM 171 in the future, these IP level resource reservation technologies would 172 be necessary in order to provide end-to-end IP flow with desired 173 bandwidth and QoS. 175 Taking this background into consideration, we should be aware of 176 several issues which motivate our proposal. 178 - As of the time of writing, the ATM specific internetworking 179 architecture proposed does not take into account interoperability 180 with IP level resource reservation or connection setup protocols. 181 In particular, operating RSVP in the NHRP-based ATM cloud seems to 182 require much effort since RSVP is a soft-state receiver-oriented 183 protocol with multicast capability as a default, while ATM with 184 NHRP is a hard-state sender-oriented protocol which does not 185 support multicast yet. 187 - Although RSVP or STII-based routers will provide each IP flow with 188 a desired bandwidth and QoS, they have some native throughput 189 limitations due to the processor-based IP forwarding mechanism 190 compared with the hardware switching mechanism of ATM. 192 The main objective of our proposal is to resolve the above issues. 194 Katsube, et al. Expires April 1997 [Page 4] 195 The proposed internetworking architecture makes the best use of the 196 property of ATM by extending legacy routers to handle future IP 197 features such as flow support and resource reservation with the help 198 of ATM's cell switching capabilities. 200 3. Internetworking Architecture Based On the Cell Switch Router (CSR) 202 3.1 Overview 204 The Cell Switch Router (CSR) is a key network element of the proposed 205 internetworking architecture. The CSR provides cell switching 206 functionality in addition to conventional IP datagram forwarding. 207 Communications with high throughput and low latency, that are native 208 properties of ATM, become possible by using this cell switching 209 functionality even when the communications pass through IP subnetwork 210 boundaries. In an ATM internet composed of CSRs, VPI/VCI-based cell 211 switching which bypasses datagram assembly/disassembly and IP header 212 processing is possible at every CSR for communications which lend 213 themselves to such (e.g., communications which require certain amount 214 of bandwidth and QoS), while conventional hop-by-hop datagram 215 forwarding based on the IP header is also possible at every CSR for 216 other conventional communications. 218 By using such cell-level switching capabilities, the CSR is able to 219 concatenate incoming and outgoing ATM VCs, although the concatenation 220 in this case is controlled outside the ATM cloud (ATM's control/ 221 management-plane) unlike conventional ATM switch nodes. That is, the 222 CSR is attached to ATM networks via an ATM-UNI instead of NNI. By 223 carrying out such VPI/VCI concatenations at multiple CSRs 224 consecutively, ATM level connectivity composed of multiple ATM VCs, 225 each of which connects adjacent CSRs (or CSR and hosts/routers), can 226 be provided. We call such an ATM pipe "ATM Bypass-pipe" to 227 differentiate it from "ATM VCC (VC connection)" provided by a single 228 ATM datalink cloud through ATM signaling. 230 Example network configurations based on CSRs are shown in figure 1. 231 An ATM datalink network may be a large cloud which accommodates 232 multiple IP subnets X, Y and Z. Or several distinct ATM datalinks 233 may accommodate single IP subnet X, Y and Z respectively. 234 The latter configuration would be straightforward in discussing the 235 CSR, but the CSR is also applicable to the former configuration as 236 well. In addition, the CSR would be applicable as a router which 237 interconnects multiple NHRP-based ATM clouds. 239 Two different kinds of ATM VCs are defined between adjacent CSRs or 240 between CSR and ATM-attached hosts/routers. 242 Katsube, et al. Expires April 1997 [Page 5] 243 1) Default-VC 245 It is a general purpose VC used by any communications which select 246 conventional hop-by-hop IP routed paths. All incoming cells received 247 from this VC are assembled to IP datagrams and handled based on their 248 IP headers. VCs set up in the Classical IP Model are classified into 249 this category. 251 2) Dedicated-VC 253 It is used by specific communications (IP flows) which are specified 254 by, for example, any combination of the destination IP address/port, 255 the source IP address/port or IPv6 flow label. It can be 256 concatenated with other Dedicated-VCs which accommodate the same IP 257 flow as it, and can constitute an ATM Bypass-pipe for those IP flows. 259 Ingress/egress nodes of the Bypass-pipe can be either CSRs or ATM- 260 attached routers/hosts both of which speak a Bypass-pipe control 261 protocol. (we call that "Bypass-capable nodes") On the other hand, 262 intermediate nodes of the Bypass-pipe should be CSRs since they need 263 to have cell switching capabilities as well as to speak the Bypass- 264 pipe control protocol. 266 The route for a Bypass-pipe follows IP routing information in each 267 CSR. In figure 1, IP datagrams from a source host or router X.1 to 268 a destination host or router Z.1 are transferred over the route X.1 269 -> CSR1 -> CSR2 -> Z.1 regardless of whether the communication is 270 on a hop-by-hop basis or Bypass-pipe basis. Routes for individual 271 Dedicated-VCs which constitutes the Bypass-pipe X.1 --> Z.1 (X.1 -> 272 CSR1, CSR1 -> CSR2, CSR2 -> Z.1) would be determined based on ATM 273 routing protocols such as PNNI[PNNI1.0], and would be independent of 274 IP level routing. 276 An example of IP datagram transmission mechanism is as follows. 278 o The host/router X.1 checks an identifier of each IP datagram, 279 which may be the "destination IP address (prefix)", 280 "source/destination IP address (prefix) pair", "destination IP 281 address and port", "source IP address and Flow label (in IPv6)", 282 and so on. Based on either of those identifiers, it determines 283 over which VC the datagram should be transmitted. 285 o The CSR1/2 checks the VPI/VCI value of each incoming cell. When 286 the mapping from the incoming interface/VPI/VCI to outgoing 287 interface/VPI/VCI is found in an ATM routing table, it is directly 288 forwarded to the specified interface through an ATM switch module. 289 When the mapping in not found in the ATM routing table (or the 291 Katsube, et al. Expires April 1997 [Page 6] 292 table shows an IP module as an output interface), the cell is 293 assembled to an IP datagram and then forwarded to an appropriate 294 outgoing interface/VPI/VCI based on an identifier of the datagram. 296 IP subnet X IP subnet Y IP subnet Z 297 <---------------------> <-----------------> <---------------------> 299 +-------+ Default +-------+ Default +-------+ Default +-------+ 300 | | -VC | CSR 1 | -VC | CSR 2 | -VC | | 301 | Host +=============+ +===============+ +=============+ Host | 302 | X.1 +-------------+++++---------------+++++-------------+ Z.1 | 303 | +-------------+++++---------------+++++-------------+ | 304 | +-------------+++++---------------+++++-------------+ | 305 | |Dedicated | | Dedicated | |Dedicated | | 306 +-------+ -VCs +-------+ -VCs +-------+ -VCs +-------+ 307 <---------------------------------------------------> 308 Bypass-pipe 310 Figure 1 Internetworking Architecture based on CSR 312 3.2 Features 314 The main feature of the CSR-based internetworking architecture is the 315 same as that of the NHRP-based architecture in the sense that they 316 both provide direct ATM level connectivity beyond IP subnet 317 boundaries. There are, however, several notable differences in the 318 CSR-based architecture compared with the NHRP-based one as follows. 320 1) Relationship between IP routing and ATM routing 322 In the NHRP model, an egress point of the ATM network is first 323 determined in the next hop resolution phase based on IP level routing 324 information. Then the actual route for an ATM-VC to the obtained 325 egress point is determined in the ATM connection setup phase based on 326 ATM level routing information. Both kinds of routing information 327 would be calculated according to factors such as network topology and 328 available bandwidth for the large ATM cloud. The ATM routing will be 329 based on PNNI phase1[PNNI1.0] while the IP routing will be based on 330 OSPF, BGP, IS-IS, etc. We need to manage two different routing 331 protocols over the large ATM cloud until Integtrated-PNNI[IPNNI96] 332 which takes both ATM level metric and IP level metric into account 334 Katsube, et al. Expires April 1997 [Page 7] 335 will be phased in in the future. 337 In the CSR model, IP level routing determines an egress point of the 338 ATM cloud as well as determines inter-subnet level path to the point 339 that shows which CSRs it should pass through. ATM level routing 340 determines an intra-subnet level path for ATM-VCs (both Dedicated-VC 341 and Default-VC) only between adjacent nodes (CSRs or ATM-attached 342 hosts/routers). Since the roles of routing are hierarchically 343 subdevided into inter-subnet level (router level) and intra-subnet 344 level (ATM SW level), ATM routing does not have to operate all over 345 the ATM cloud but only in individual IP subnets independent from each 346 other. This will decrease the amount of information for ATM routing 347 protocol handling. But an end-to-end ATM path may not be optimal 348 compared with the NHRP model since the path should go through routers 349 at subnet boundaries in the CSR model. 351 2) Dynamic routing and redundancy support 353 A CSR-based network can dynamically change routes for Bypass-pipes 354 when related IP level routing information changes. Bypass-pipes 355 related to the routing changes do not have to be torn down nor 356 established from scratch since intermediate CSRs related to IP 357 routing changes can follow them and change routes for related 358 Bypass-pipes by themselves. 360 The same things apply when some error or outage happens in any ATM 361 nodes/links/routers on the route of a Bypass-pipe. CSRs that have 362 noticed such errors or outages would change routes for related 363 Bypass-pipes by themselves. 365 3) Interoperability with IP level resource reservation protocols in 366 multicast environments 368 As current NHRP specification assumes application of NHRP to unicast 369 environments only, multicast IP flows should still be carried based 370 on a hop-by-hop manner with multicast routers. In addition, 371 realization of IP level resource reservation protocols such as RSVP 372 over NHRP environments requires further investigation. 374 The CSR-based internetworking architecture which keeps subnet-by- 375 subnet internetworking with regard to any control protocol sequence 376 can provide multicast Bypass-pipes without requiring any 377 modifications in IP multicast over ATM[IPMC96] or multicast routing 378 techniques. In addition, since the CSR can handle RSVP messages 379 which are transmitted in a hop-by-hop manner, it can provide Bypass- 380 pipes which satisfy QoS requirements by the cooperation of the RSVP 381 and the Bypass-pipe control protocol. 383 Katsube, et al. Expires April 1997 [Page 8] 384 4. Control Architecture for CSR 386 Several issues with regard to a control architecture for the CSR are 387 discussed in this section. 389 4.1 Network Reference Model 391 In order to help understanding discussions in this section, the 392 following network reference model is assumed. Source hosts S1, S2, 393 and destination hosts D1, D2 are attached to Ethernets, while S3 and 394 D3 are attached to the ATM. Routers R1 and R5 are attached to 395 Ethernets only, while R2, R3 and R4 are attached to the ATM. The ATM 396 datalink for subnet #3 and subnet #4 can either be physically 397 separated datalinks or be the same datalink. In other words, R3 can 398 be either one-port or multi-port router. 400 Ether Ether ATM ATM Ether Ether 401 | | +-----+ +-----+ | | 402 | | | | | | | | 403 S1--| S2---| S3---| | | |---D3 |---D2 |--D1 404 | | | | | | | | 405 |---R1---|---R2---| |--R3--| |---R4---|---R5---| 406 | | | | | | | | 407 | | +-----+ +-----+ | | 408 subnet subnet subnet subnet subnet subnet 409 #1 #2 #3 #4 #5 #6 411 Figure 2 Network Reference Model 413 Bypass-pipes can be configured [S3 or R2]-->R3-->[D3 or R4]. That 414 means that S3, D3, R2, R3 and R4 need to speak Bypass-pipe control 415 protocol, and means that R3 needs to be the CSR. We use term 416 "Bypass-capable nodes" for hosts/routers which can speak Bypass-pipe 417 control protocol but are not necessarily CSRs. 419 As shown in this reference model, Bypass-pipe can be configured from 420 host to host (S3-->R3-->D3), router to host (R2-->R3-->D3), host to 421 router (S3-->R3-->R4), and router to router (R2-->R3-->R4). 423 4.2 Possible Use of Bypass-pipe 425 Katsube, et al. Expires April 1997 [Page 9] 426 Possible use (or purposes) of Bypass-pipe provided by CSRs, in other 427 words, possible triggers that initiate Bypass-pipe setup procedure, 428 is discussed in this subsection. 430 Following two purposes for Bypass-pipe setup are assumed at present; 432 a) Provision of low latency path 434 This indicates cases in which end hosts or routers initiate a 435 Bypass-pipe setup procedure when they will transmit large amount of 436 datagrams toward a specific destination. For instance, 438 - End hosts or routers initiate Bypass-pipe setup procedures based 439 on the measurement of IP datagrams transmitted toward a certain 440 destination. 442 - End hosts or routers initiate Bypass-pipe setup procedures when 443 it detects datagrams with certain higher layer protocols such as 444 ftp, nntp, http, etc. 446 Other triggers may be possible depending on the policy in each 447 network. In any case, the purpose of Bypass-pipe setup in each of 448 these cases is to reduce IP processing burden at intermediate routers 449 as well as to provide a communication path with low latency for burst 450 data transfer, rather than to provide end host applications with 451 specific bandwidth/QoS. 453 There would be no rule for determining bandwidth for such kinds of 454 Bypass-pipes since no explicit information about bandwidth/QoS 455 requirement by end hosts is available without IP-level resource 456 reservation protocols such as RSVP. Using UBR VCs as components of 457 the Bypass-pipe would be the easiest choice although there is no 458 guarantees for cell loss quality, while using other services such as 459 CBR/VBR/ABR with an adequate parameter tuning would be possible. 461 b) Provision of specific bandwidth/QoS requested by hosts 463 This indicates cases in which routers or end hosts initiate a 464 Bypass-pipe setup procedure by triggers related to IP-level 465 bandwidth/QoS request from end hosts. The "resource management 466 entity" in the host or router, which has received bandwidth/QoS 467 requests from applications or adjacent nodes may choose to 468 accommodate the requested IP flow to an existing VC or choose to 469 allocate a new Dedicated-VC for the requested IP flow. Selecting 470 the latter choice at each router can correspond to the trigger for 471 constituting a Bypass-pipe. When both an incoming VC and an outgoing 472 VC (or VCs) are dedicated to the same IP flow(s), those VCs can be 473 concatenated at the CSR (ATM cut-through) to constitute a Bypass- 474 pipe. Bandwidth for the Bypass-pipe (namely, individual VCs 475 constituting the Bypass-pipe) in this case would be determined based 476 on the bandwidth/QoS requirements by the end host which is conveyed 477 by, e.g., RSVP messages. The ATM service classes; e.g., CBR/VBR/ABR; 478 that would be selected depends on the IP-level service classes 479 requested by the end hosts. 481 Bypass-pipe provision for the purpose of b) will surely be beneficial 482 in the near future when related IP-level resource reservation 483 protocol will become available as well as when definitions of 484 individual service classes and flow specs offered to applications 485 become clear. On the other hand, Bypass-pipe setup for the purpose 486 of a) may be beneficial right now since it does not require 487 availability of IP-level resource reservation protocols. In that 488 sense, a) can be regarded as a kind of short-term use while b) is a 489 long-term use. 491 4.3 Variations of Bypass-pipe Control Architecture 493 A number of variations regarding Bypass-pipe control architecture 494 are introduced. Items which are related to architectural variations 495 are; 497 o Ways of providing Dedicated-VCs 499 o Channels for Bypass-pipe control message transfer 501 o Bypass-pipe control procedures 503 Each of these items are discussed below. 505 4.3.1 Ways of Providing Dedicated-VCs 507 There are roughly three alternatives regarding the way of providing 508 Dedicated-VCs in individual IP subnets as components of a Bypass- 509 pipe. 511 a) On-demand SVC setup 513 Dedicated-VCs are set up in individual IP subnets each time you want 514 to set up a Bypass-pipe through the ATM signaling procedure. 516 b) Picking up one from a bunch of (semi-)PVCs 518 Several VCs are set up beforehand between CSR and CSR, or CSR and 519 other ATM-attached nodes (hosts/router) in each IP subnet. 520 Unused VC is picked up as a Dedicated-VC from these PVCs in each IP 521 subnet when a Bypass-pipe is set up. 523 c) Picking up one VCI in PVP/SVP 525 PVPs or SVPs are set up between CSR and CSR, or CSR and other ATM- 526 attached nodes (hosts/routers) in each IP subnet. PVPs would be set 527 up as a router/host initialization procedure, while SVPs, on the 528 other hand, would be set up through ATM signaling when the first VC 529 (either Default- or Dedicated-) setup request is initiated by either 530 of some peer nodes. Then, Unused VCI value is picked up as a 531 Dedicated-VC in the PVP/SVP in each IP subnet when a Bypass-pipe is 532 set up. The SVP can be released through ATM signaling when no VCI 533 value is in active state. 535 The best choice will be a) with regard to efficient network resource 536 usage. However, you may go through three steps, ATMARP (for unicast 537 [RFC1577] or multicast[IPMC96] in each IP subnet), SVC setup (in each 538 IP subnet) and exchange of Bypass-pipe control message in this case. 539 Whether a) is practical choice or not will depend on whether you can 540 allow larger Bypass-pipe setup time due to three-step procedure 541 mentioned above, or whether you can send datagrams over Default-VCs 542 in a hop-by-hop manner while waiting for the Bypass-pipe set up. 544 In the case of b) or c), the issue of Bypass-pipe setup time will be 545 improved since SVC setup step can be skipped. In b), each node (CSR 546 or ATM-attached host/router) should specify some traffic descriptors 547 even for unused VCs, and the ATM datalink should reserve its desired 548 resource (such as VCI value and bandwidth) for them. In addition, 549 the ATM datalink may have to carry out UPC functions for those unused 550 VCs. Such burden would be reduced when you use UBR-PVCs and set 551 peak cell rate for each of them equal to link rate, but bandwidth/QoS 552 for the Bypass-pipe is not provided in this case. In c), on the 553 other hand, traffic descriptors which should be specified by each 554 node for the ATM datalink is not each VC's but VP's only. Resource 555 reservations for individual VCs will be carried out not as a 556 functionality of the ATM datalink but of each CSR or ATM-attached 557 host/router if necessary. A functionality which need to be provided 558 by the ATM datalink is control of VPs' bandwidth only such as UPC and 559 dynamic bandwidth negotiation if it would be widely available. 561 4.3.2 Channels for Bypass-pipe Control Message Transfer 563 There are several alternatives regarding the channels for managing 564 (setting up, releasing, and possibly changing the route of) a 565 Bypass-pipe. This subsection explains these alternatives and 566 discusses their properties. 568 Three alternatives are discussed, Inband control message, Outband 569 control message, and use of ATM signaling. 571 i) Inband Control Message 573 When setting up a Bypass-pipe, control messages are transmitted over 574 a Dedicated-VC which will eventually be used as a component of the 575 Bypass-pipe. These messages are handled at each CSR, and similar 576 messages are transmitted to the next-hop node over a Dedicated-VC 577 along the selected route (based on IP routing table). Unlike 578 outband message protocol described in ii), each message does not have 579 to indicate a Dedicated-VC which will be used since the message 580 itself is carried over "that" VC. 582 The inband control message can be either "datagram dedicated for 583 Bypass-pipe control" or "actual IP datagram" sent by user 584 application. Actual IP datagrams can be transmitted over Bypass-pipe 585 after it has been set up in the former case. In the latter case, on 586 the other hand, the first (or several) IP datagram(s) received from 587 an unused Dedicated-VC are analyzed at IP level and transmitted 588 toward adequate next hop over an unused Dedicated-VC. Then incoming 589 Dedicated-VC and outgoing Dedicated-VC are concatenated to construct 590 a Bypass-pipe. 592 In inband control, Bypass-pipe control messages transmitted after a 593 Bypass-pipe has been set up cannot be identified at intermediate CSRs 594 since those messages are forwarded at cell level there. As a 595 possible solution for this issue, intermediate CSRs can identify 596 Bypass-pipe control messages by marking cell headers, e.g., PTI bit 597 which indicates F5 OAM cell. With regard to Bypass-pipe release, 598 explicit release message may not be necessary if individual CSRs 599 administer the amount of traffic over each Dedicated-VC and deletes 600 concatenation information for an inactive Bypass-pipe with their own 601 decision. 603 ii) Outband Control Message 605 When a Bypass-pipe is set up or released, control messages are 606 transmitted over VCs which are different from Dedicated-VCs used as 607 components of the Bypass-pipe. Unlike inband message protocol 608 described in i), each message has to indicate which Dedicated-VCs 609 the message would like to control. Therefore, an identifier that 610 uniquely discriminates a VC, which is not a VPI/VCI that is not 611 identical at both endpoints of the VC, need to be defined and be 612 given at VC initiation phase. However, an issue of control message 613 transmission after a Bypass-pipe has been set up in inband case does 614 not exist. 616 Four alternatives are possible regarding how to convey Bypass-pipe 617 control messages hop-by-hop over ATM datalink networks. 619 1) Defines VC for Bypass-pipe control messages only. 621 2) Uses Default-VC and discriminates Bypass-pipe control messages 622 from user datagrams by an LLC/SANP value in RFC1483 encapsulation. 624 3) Uses Default-VC and discriminates Bypass-pipe control messages 625 from user datagrams by a protocol field value in IP header. 627 4) Uses Default-VC and discriminates Bypass-pipe control messages 628 from user datagrams by a port ID in the UDP frame. 630 When we take into account interoperability with Bypass-incapable 631 routers, 1) will not be a good choice. Whether we select 2) or 3) 4) 632 depends on whether we should consider multiprotocol rather than IP 633 only. 635 In the case of IP multicast, point-to-multipoint VCs in individual 636 subnets are concatenated at CSRs consecutively in order to constitute 637 end-to-end multicast tree. Above four alternatives may require the 638 same number of point-to-multipoint Defalut-VCs as the number of 639 requested point-to-multipoint Dedicated-VCs in multicast case. The 640 fifth alternative which can reduce the necessary number of VCs to 641 convey control messages in a multicast environment is; 643 5) Defines point-to-multipoint VC whose leaves are members of 644 multicast group 224.0.0.1. All nodes which are members of at 645 least one of active multicast group would become leaves of this 646 point-to-multipoint VC. 648 Each upstream node may become a root of the point-to-multipoint VC, 649 or a sort of multicast server to which each upstream node transmits 650 cells over a point-to-point VC may become a root of that. In any 651 case, Bypass-pipe control messages for every multicast group are 652 transmitted to all nodes which are members of either of the group. 653 When a downstream node has received control messages which are not 654 related to a multicast group it belongs, it should discard them 655 by referring to a destination group address on their IP header. 656 Donwstream node would still need to use point-to-point VC to send 657 control messages toward upstream. 659 iii) Use of ATM Signaling Message 660 Supposing that ATM signaling messages can convey IP addresses (and 661 possibly port IDs) of source and destination, it may be possible that 662 ATM signaling messages be used as Bypass-pipe control messages also. 663 In that case, an ATM connection setup message indicates a setup of a 664 Dedicated-VC to an ATM address of a desirable next-hop IP node, and 665 also indicates a setup of a Bypass-pipe to an IP address (and 666 possibly port ID) of a target destination node. Information elements 667 for the Dedicated-VC setup (ATM address of a next-hop node, 668 bandwidth, QoS, etc.) are handled at ATM nodes, while information 669 elements for the Bypass-pipe setup (source and destination IP 670 addresses, possibly their port IDs, or flow label for IPv6, etc.) are 671 transparently transferred to the next-hop IP node. The next-hop IP 672 node accepts Dedicated-VC setup and handles such IP level information 673 elements. 675 ATM signaling messages can be transferred from receiver to sender as 676 well as sender to receiver when you set zero Forward Cell Rate and 677 non-zero Backward Cell Rate as an ATM traffic descriptor information 678 element in unicast case, or when Leaf Initiated Join capabilities 679 will become available in multicast case. 681 Issues in this method are, 683 - Information elements which specify IP level (and port level) 684 information need to be defined, e.g., B-HLI or B-UUI, as an ATM 685 signaling specification. 687 - It would be difficult to support soft-state Bypass-pipe control 688 which transmits control messages periodically since ATM signaling 689 is a hard-state protocol. 691 4.3.3 Bypass-pipe Control Procedures 693 This subsection discusses several items with regard to actual 694 procedures for Bypass-pipe control. 696 a) Distributed trigger vs. Centralized (restricted) trigger 698 The first item to be discussed is whether the functionality of 699 detecting a trigger of Dedicated-VC/Bypass-pipe control is 700 distributed to all the nodes (including CSRs and hosts/edge devices) 701 or restricted to specific nodes. 703 In the case of the distributed trigger, every node is regarded as 704 having a capability of detecting a trigger of Bypass-pipe setup or 705 termination. For example, every node detects datagrams for ftp, and 706 sets up (or fetches) a Dedicated-VC individually to construct a 707 Bypass-pipe. After setting up or fetching the Dedicated-VCs, 708 messages which informs (or requests) the transmission of the IP flow 709 over the Dedicated-VC are exchanged between adjacent nodes. That 710 enables peer nodes to share the same knowledge about the mapping 711 relationship between the IP flow and the Dedicated-VC. There is no 712 end-to-end message transmission in the Bypass-pipe control procedure 713 itself, but transmission between adjacent nodes only. 715 In the case of the centralized (or restricted) trigger, capability 716 of detecting a trigger of Bypass-pipe setup or termination is 717 restricted to nodes which are located at "the boundary of the CSR- 718 cloud". The boundary of the CSR-cloud signifies, for individual IP 719 flows, the node which is the first-hop or the last-hop CSR-capable 720 node. For example, a node which detects datagrams for ftp can 721 initiate Bypass-pipe setup procedure only when its previous hop is 722 non-ATM or CSR-incapable. In this case, Bypass-pipe control messages 723 are originated at the boundary of the CSR-cloud, and forwarded 724 hop-by-hop toward another side of the boundary, which is similar to 725 ATM signaling messages. The semantics of the messages may be the 726 request of end-to-end Bypass-pipe setup as well as notification or 727 request of mapping relationship between the IP flow and the 728 Dedicated-VC. 730 b) Upstream-initiated control vs. Downstream-initiated control 732 The second item to be discussed is whether the setup of a Dedicated- 733 VC and the control procedure for constructing a Bypass-pipe are 734 initiated by upstream side or downstream side. 736 In the case of the upstream-initiated control, the upstream node 737 takes the initiative when setting up a Dedicated-VC for a specific IP 738 flow and creating the mapping relationship between the IP flow and 739 the Dedicated-VC. For example, a CSR which detects datagrams for 740 ftp sets up (or fetches) a Dedicated-VC toward its downstream 741 neighbor and notifies its downstream neighbor that it will transmit 742 a specific IP flow over the Dedicated-VC. This means that the 743 downstream node is requested to receive datagrams from the 744 Dedicated-VC. 746 In the case of the downstream-initiated control, the downstream node 747 takes the initiative when setting up a Dedicated-VC for a specific 748 IP flow and creating the mapping relationship between the IP flow 749 and the Dedicated-VC. For example, a CSR which detects datagrams for 750 ftp sets up (or fetches) a Dedicated-VC toward its upstream neighbor 751 and requests its upstream neighbor to transmit a specific IP flow 752 over the Dedicated-VC. This means that the upstream node is 753 requested to transmit the IP flow over the Dedicated-VC. 755 c) Hard-state management vs. Soft-state management 757 The third item to be discussed is whether the control (setup, 758 maintain, and release) of the Bypass-pipe is based on hard-state or 759 soft-state. 761 In hard-state management, individual nodes transmit Bypass-pipe 762 control messages only when they want to notify or request any 763 change in their neighbors' state. They should wait for an 764 acknowledgement of the message before they change their internal 765 state. For example, after setting up a Bypass-pipe, it is maintained 766 until either of a peer nodes transmits a message to release the 767 Bypass-pipe. 769 In soft-state management, individual nodes periodically transmit 770 Bypass-pipe control messages in order to maintain their neighbors' 771 state. They do not have to wait for an acknowledgement of the 772 message before they changes its internal state. For example, even 773 after setting up a Bypass-pipe, either of a peer nodes is required 774 to periodically transmit refresh messages to its neighbor in order 775 to maintain the Bypass-pipe. 777 5. Security Considerations 779 Security issues are not discussed in this memo. 781 6. Summary 783 Basic concept of Cell Switch Router (CSR) are clarified and control 784 architecture for CSR is discussed. A number of methods to control 785 Bypass-pipe will be possible each of which has its own advantages 786 and disadvantages. Further investigation and discussion will be 787 necessary to design control protocol which may depend on the 788 requirements by users. 790 7. References 792 [IPMC96] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based 793 ATM Networks", IETF Internet Draft (work in progress), draft-ietf- 794 ipatm-ipmc-12.txt, Feb. 1996. 796 [ATM3.1] The ATM-Forum, "ATM User-Network Interface Specification, 797 v.3.1", Sept. 1994. 799 [RSVP13] R. Braden, et al., "Resource ReSerVation Protocol (RSVP), 800 Version 1 Functional Specification", IETF Internet Draft (work in 801 progress), draft-ietf-rsvp-spec-13.ps/txt, Aug. 1996. 803 [IPNNI96] R. Callon, et al., "Issues and Approaches for Integrated 804 PNNI", The ATM Forum Contribution No. 96-0355, April 1996. 806 [NHRP09] J. Luciani, et al., "NBMA Next Hop Resolution Protocol 807 (NHRP)", IETF Internet Draft (work in progress), draft-ietf-rolc- 808 nhrp-09.txt, July 1996. 810 [PNNI1.0] The ATM-Forum, "P-NNI Specification Version 1.0", March 811 1996. 813 [RFC1483] J. Heinanen, "Multiprotocol Encapsulation over ATM 814 Adaptation Layer 5", IETF RFC 1483, July 1993. 816 [RFC1577] M. Laubach, "Classical IP and ARP over ATM", IETF RFC 1577, 817 Oct. 1993. 819 [RFC1819] L. Delgrossi and L. Berger, "Internet STream Protocol 820 Version 2(STII) Protocol Specification Version ST2+", IETF RFC 1819, 821 Aug. 1995. 823 8. Authors' Address 825 Yasuhiro Katsube 826 R&D Center, Toshiba 827 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 828 Japan 829 Phone : +81-44-549-2238 830 Email : katsube@isl.rdc.toshiba.co.jp 832 Ken-ichi Nagami 833 R&D Center, Toshiba 834 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 835 Japan 836 Phone : +81-44-549-2238 837 Email : nagami@isl.rdc.toshiba.co.jp 839 Hiroshi Esaki 840 R&D Center, Toshiba 841 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 842 Japan 843 Phone : +81-44-549-2238 844 Email : hiroshi@isl.rdc.toshiba.co.jp