idnits 2.17.1 draft-ohta-sun-01.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-19) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == 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 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 (March 1997) is 9897 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) == Missing Reference: 'RFC1620' is mentioned on line 51, but not defined == Unused Reference: 'RFP1620' is defined on line 279, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CSR1' -- Possible downref: Non-RFC (?) normative reference: ref. 'CSR2' -- Possible downref: Non-RFC (?) normative reference: ref. 'IFMP' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFP1620' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVP' -- Possible downref: Non-RFC (?) normative reference: ref. 'ST2' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT M. Ohta 3 draft-ohta-sun-01.txt Tokyo Institute of Technology 4 March 1997 6 Simple Unified Networking 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 22 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 The concept of LIS for IP over ATM causes a topology mismatch between 29 the link and the internetworking layer. While it introduces some 30 inefficiency with CATENET based operation, it is not so much a 31 problem unless we try to solve this minor problem. 33 Short-cutting attempts such as NHRP can't solve the inefficiency 34 issue at all even though, or, just because, it utterly destroys the 35 CATENET model, which resulted in inelegant modifications of existing 36 protocols, which, in turn, causes scalability problems. 38 Moreover, the creation of short-cut VCs itself suffers a scalability 39 issue. 41 But, CSRs (Cell Switching Routers), or RSVP-signaled ATM switches, 42 make it possible to have end-to-end cell-by-cell relaying over IP 43 routers. That is, there is no reason to have LISes and there is no 44 inefficiency 46 The way to go for the Internet is Simple Unified Networking with the 47 CATENET model. 49 1. Introduction 51 See RFC1620 [RFC1620]. 53 2. Inefficiency Remains 55 On the Internet today, routing metric roughly approximate the real 56 distance between networks. As a result, semi-optimal routing over 57 the Internet is possible, though some policy restriction may impose 58 some additional detour. 60 But, with the LIS model mentioned in RFC1620, routing metric has 61 nothing to do with the real distance. This is not a problem within 62 an NBMA with link layer shortcutting where link layer metric is the 63 approximated metric. 65 That is, when an NBMA is a leaf of the Internet with only a single 66 entry router to the rest of the Internet, there is no inefficiency 67 problem. 69 But, in such a case, shortcutting in NBMA is a local optimization 70 issue unrelated to the Internet architecture. 72 Otherwise, when the leaf NBMA has multiple entry routers or when a 73 host in the NBMA is multihomed, the distortion causes inefficient 74 routing. 76 Finally, when the NBMA is not leaf but a transit network, the 77 distorted metric can pollute the rest of the Internet to be a serious 78 inefficiency problem. 80 For example, consider the following configuration: 82 Ha Hb Hc Hd 84 | | | | 85 ---- | ---------- | ---------- | ---------- | ---- 86 | __|__ __|__ __|__ __|__ | 87 ( ) ( ) ( ) ( ) 88 | ( ) ( ) ( ) ( ) | 89 ( Net ) ( Net ) ( Net ) ( Net ) 90 | ( A ) ( B ) ( C ) ( D ) | 91 ( ) ( ) ( ) ( ) 92 | ( ) ( ) ( ) ( ) | 93 (_____) (_____) (_____) ( ____) 94 | | | | | | | | | | 95 --- | | -------- | | -------- | | -------- | | --- 96 | | | | | | | | 98 R1 - --- R2 --- --- R3 --- --- R4 --- --- R5 99 | | 100 ---------------- R6 --------------- R7 ---------- 101 | 102 He 104 where Nets A, B, C and D are highly logical LIS in a large shared 105 medium network. 107 For example, suppose R1 is located at Munich, Ha Sunnyvale, R2 108 Montreal, R3 Memphis, R4 Kuala Lumpur, Hd San Jose, R5 Mountain View, 109 R6 Danvers, R7 Menlo Park, and He Palo Alto. 111 Then, without shortcutting, Ha and Hd may communicate hop-by-hop from 112 Sunnyvale, Montreal, Memphis, Kuala Lumpur and finally to San Jose. 113 Not an inefficient path. 115 The problem is that routing metric at the Internetworking layer does 116 not reflect the real world metric at all. 118 But, if we can somehow make use of the fact that Ha and Hd are placed 119 in a single shared medium, Ha and Hd can communicate locally within 120 Silicon Valley between Sunnyvale and San Jose. 122 That's the inefficiency issue that mechanisms in RFC 1620 wanted to 123 resolve. 125 The problem is that though the inefficiency may be removed within the 126 shared medium, it's not the only inefficiency. 128 When Ha and He communicate over a path Ha-R6-R7-He, the traffic will 129 pass from Sunnyvale, Munich, Danvers, Menlo Park and finally to Palo 130 Alto, even though the path Ha-R5-R7-He exists within Silicon Valley. 132 The inefficiency can be avoided by reducing metric within the shared 133 medium. But, it causes other type of inefficiency. That is, the 134 shared medium will be used for transit even though the physically 135 shortest path exists outside of it. 137 The problem is that routing metric at the Internetworking layer 138 within the shared media does not reflect the real world metric at 139 all. 141 When a LIS contains hosts at room 1035, Fairmont Hotel, San Jose; 142 room 1036, Fairmont Hotel, San Jose; Holidy Inn San Jose; Palo Alto; 143 Los Angels and Munich; there is no meaningful metric for the LIS to 144 be used outside of the LIS. 146 Also, It is obvious that no intra-shared-media protocol can solve the 147 route selection problem outside of the medium at R7. 149 That is, routing metric should be mostly proportional to the physical 150 distance. Then, the least metric path will be almost optimal. 152 It means that LISes should not be so logical and mostly contiguous. 154 As a result, the CATENET model with no extension works efficiently 155 over the shared media. 157 3. Inscalability Problems 159 3.1 RSVP Inscalability 161 As the Internet protocols are designed with the CATENET model, 162 modification to the model naturally makes some protocol not work and 163 other protocol not to scale. 165 For example, RSVP scales to the number of recipients because RESV 166 messages are merged on routers upstream toward the sender. 168 But, in a large shared medium with no intermediate entity to 169 recognize IP, merger of the RESV messages is impossible. 171 As it is essential to merge RESV at the data branch point, RESV 172 merging servers external to the shared medium does not work. 174 That is, all the RESV messages concentrate and implode at the 175 upstream most router or the sender on the shared medium, which means 176 not so many recipients can be supported. 178 Note that, in the worst case when most of the hosts in the shared 179 medium are the recipients, the amount of imploding packets is almost 180 equal to the amount of ATMARP packets for a single ATMARP server 181 receives, if the entire shared medium is served by a single ATMARP 182 server. 184 That is, on multicast-aware shared medium, it's enough to make the 185 entire medium a single subnet, maybe with SCSP. 187 3.2 VC Shortage at the Egress Router 189 It is unlikely that the Internet mostly consists of a large single 190 shared medium. 192 Thus, when hosts in a shared medium wants to communicate to the 193 Internet outside of the medium, the egress routers must be directly 194 connected to each such host through a dedicated VC. 196 But, shared medium can support only a limited number of VCs for a 197 single node. 199 On existing commercial shared medium service such as X.25 or 200 framerelay, it is typical that the number of supported VCs is less 201 than 100. 203 It is typical that ATM switches can support only several thousands of 204 VCs for each port. 206 Thus, not so many hosts can communicate with the external Internet 207 efficiently 209 Other hosts can still communicate hop-by-hop. But, as the size of the 210 shared medium glows, the efficiency as a whole approaches that of 211 hop-by-hop. 213 That is, it is necessary to make the hop-by-hop communication 214 efficient by not making LISes logical, which means that no 215 inefficiency exist to be removed by shortcutting attempt. 217 4. Cell Switching Routers 219 It seems to the Author that some people thought that cell-by-cell 220 relaying was impossible over IP routers, which, seemingly, motivated 221 them to support shortcutting over ATM shared medium. 223 While it was understandable, cell-by-cell relaying over IP routers is 224 possible. 226 The point is that it is possible to signal ATM switches with RSVP 227 [RSVP], ST2 [ST2], IFMP [IFMP] or some other IP-based signaling 228 protocol. 230 Then, switch-local traffic control module sets up the cell switching 231 fabric appropriately. 233 The ATM switch signaled by IP is, in general, called CSR (Cell 234 Switching Routers) [CSR1, CSR2]. 236 CSR is merely one of several ways to build a router and this memo 237 does not recommend nor discourage to deploy the technology. 239 5. Conclusion. 241 RFC 1620 was wrong. 243 While it suggests several ways to have shortcuts, note that the 244 discussions in section 2 and 3 does not depend on how the shortcuts 245 are created. That is, modifications on the way to have shortcuts does 246 not affect the conclusion that they are no good. 248 It is not necessary nor possible to modify the CATENET model, the 249 architecture of the Internet, to have efficient and scalable Internet 250 to accommodate shared medium such as ATM. 252 Shortcutting attempt, such as NHRP, may still be used in LAN or WAN 253 NBMA environment with a small number of hosts. But, if the number of 254 hosts is small, it is often, if not always, possible to make the 255 entire NBMA a single LIS. Anyway, these local optimization does not 256 affect the global architecture of the Internet. 258 The Simple Unified Networking with the CATENET model is the way to 259 go. 261 6. Acknowledgements 263 Thank you Joel Halpern Sam Wilson and other members of ION working 264 group for constructive comments to improve the quality of the memo. 266 7. References 268 [CSR1] Hiroshi ESAKI, Ken-ichi NAGAMI, Masataka OHTA, "High Speed 269 Datagram Delivery over Internet using ATM Technology", 270 Networld+Interop '95 Engineer Conference, E12-1~E12-9, (1995). 272 [CSR2] Yukinori GOTO, Masataka OHTA, Masaki HIRABARU, "Design of 273 Internet Resource Reservation on ATM Network", Proceedings of The 274 10th International Conference on Information Networking (ICOIN-10), 275 pp.510-516, 1996. 277 [IFMP] 279 [RFP1620] 281 [RSVP] 283 [ST2] 285 8. Security Considerations 287 (to be filled) 289 9. Author's Address 290 Masataka Ohta 291 Computer Center 292 Tokyo Institute of Technology 293 2-12-1, O-okayama, Meguro-ku 294 Tokyo 152, JAPAN 296 Phone: +81-3-5734-3299 297 Fax: +81-3-5734-3415 298 EMail: mohta@necom830.hpcl.titech.ac.jp