idnits 2.17.1 draft-ietf-ion-intra-area-unicast-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. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (November 1997) is 9652 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) ** Downref: Normative reference to an Experimental draft: draft-ietf-ion-intralis-multicast (ref. '1') ** Obsolete normative reference: RFC 1483 (ref. '2') (Obsoleted by RFC 2684) -- No information found for draft-ietf-ion-sig-uni4 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Juha Heinanen 2 INTERNET DRAFT Telia Finland 3 Expires May 1998 November 1997 5 Intra-area IP unicast among routers over legacy ATM 6 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 Shadow 22 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 This document describes how IP unicast can be efficiently implemented 29 among routers belonging to the same area of a routing domain, where 30 the connectivity is provided by a legacy ATM network as defined by 31 the ATM Forum or ITU. This proposal is designed to be complementary 32 to IP multicast solutions such as the one described in [1]. 34 1. Introduction 36 This document describes how a set of routers (such as the access/edge 37 routers of an ISP or enterprise) connected to a legacy ATM network 38 can in a dynamic and plug-and-play fashion optimize ATM connections 39 for efficient forwarding of unicast IP packets. The method can be 40 used in situations where the number of routers is so large that a 41 full mesh of point-to-point ATM VCs is not practical from technical 42 or economic reasons. In addition, it can be applied to smaller 43 router networks to automate the setup of a full mesh of ATM 44 connectivity between the routers. 46 The set of routers must belong to the same area of a link state 47 routing protocol, such as OSPF or IS-IS, that floods topology and 48 reachability information to every router in the area. 50 This proposal only deals with IP unicast, but it complements and can 51 be used in conjunction with IP multicast solutions such as the one 52 described in [1]. 54 2. Router configuration and behavior 56 Initialization 58 As introduced above, this document defines a method of dynamically 59 managing ATM connectivity among a set of routers that belong to the 60 same area of a routing domain, where a link state protocol, such as 61 OSPF or IS-IS, is used to exchange topology and reachability 62 information. 64 Before the dynamic management of ATM VCs can begin, the routers of 65 the area must be manually configured to exchange routing information 66 among themselves. There must thus be enough initial connectivity so 67 that at least one IP path exists from each router to each other 68 router in the area. This initial connectivity is also used to 69 forward IP packets when dynamic ATM VCs don't exist. 71 Note that the initial connectivity doesn't necessarily need to be 72 implemented over ATM and that not all routers of the area need to be 73 ATM attached. Furthermore, even if a router is ATM attached, it 74 doesn't need to participate in the dynamic management of ATM VCs. 75 The ATM routers of an area can thus be upgraded one at a time to 76 support the method described in this document. 78 Connection setup and teardown 80 After the initial connectivity has been established, ATM attached 81 routers that participate in this method start to dynamically create 82 and delete dynamic shortcut ATM VCs among themselves based on traffic 83 volumes. This can be accomplished, for example, as follows. 85 An ATM attached router R measures, how many bytes it has received 86 during the past M seconds, whose final hop router S within the area 87 is also ATM attached. If the number of bytes is less than N, R 88 forwards the packets according to its routing table. When the number 89 of bytes equals or exceeds N, and R doesn't yet have a dynamic ATM VC 90 to S, R creates such a VC and starts to forward S bound packets 91 directly. 93 Once the dynamic ATM VC from R to S has been created, R starts to 94 measure the traffic along it. When R detects that during the past K 95 seconds the number of bytes along the dynamic ATM VC to S has fallen 96 below L, it deletes the dynamic ATM VC and returns to the initial 97 mode of operation that was described above. 99 The values of the constants K, L, M, and N control the rate of 100 dynamic ATM VC creation and teardown. They are assigned by the 101 network administrator and may differ from one ATM attached router to 102 another. 104 Setting the VC creation and deletion limits N and L to zero, turns 105 off the measurement process and causes the router to create a dynamic 106 VC to every other participating router. That can be the default in 107 small router networks that want to use this method to automate the 108 setup of a full mesh of ATM VCs. 110 If a router doesn't want to set up any dynamic ATM VCs, the VC 111 creation limit N is set to a positive value and the measurement 112 interval M is set to zero. Finally, if a router doesn't want to be a 113 destination of dynamic ATM VCs, it doesn't make its ATM address 114 available to the other routers for the purpose of this application. 116 Note that if a router is not capable in measuring traffic, it can 117 still participate as a destination of dynamic ATM VCs and can itself 118 set up dynamic VCs non-selectively to every other router. 120 Characteristics of dynamic ATM VCs 122 In order to keep the number of routing peers small and in order to 123 avoid frequent changes in topology information, the router that 124 establishes a dynamic ATM VC does not use it for the exchange of 125 routing information nor does it advertise the dynamic VC to its 126 routing peers. 128 Dynamic ATM VCs are unidirectional, because the source router that 129 established a dynamic ATM VC does not have information about the 130 traffic volumes to the reverse direction. Unidirectionality also 131 simplifies the method, since it allows the source router to manage 132 the dynamic ATM VC autonomously without coordination with the 133 destination router. Yet another advantage of unidirectionality is 134 that unidirectional VCs can be merged if more than one source router 135 sets up a connection to the same destination router. 137 The traffic category, traffic parameters, and protocol encapsulation 138 of dynamic ATM VCs are a local matter of the routers that establish 139 them. The default traffic category is UBR with peak cell rate set to 140 the link rate and minimal acceptable cell rate (if applicable) set to 141 zero. The default protocol encapsulation method is LLC Encapsulation 142 as defined in [2]. Signalling is as specified in [3] for UNI 3.1 and 143 in [4] for UNI 4.0. 145 3. Address resolution 147 Since all the routers belong to the same area of a link state routing 148 domain, they learn each others' router IDs and the IP address 149 prefixes that are reachable via each router. In order to dynamically 150 create an ATM VC from one router to another, the source router also 151 needs to learn the ATM address of the destination router. 153 A router that wants to participate as a destination in the dynamic 154 management of ATM VCs, makes its ATM address known to the other 155 routers of the area by including in its link state advertisements a 156 field that contains an ATM address of the advertising router. 158 In OSPF, the router advertises its ATM address(es) using the Address 159 Resolution Advertisement (ARA) option [5]. The Opaque Type of the 160 ARA is Intra-area Router ARA (Opaque Type-1). One or more ATM 161 addresses or LIJ identifications (one per Vertex Association) can be 162 advertised in a single ARA. The Resolution Type of a Vertex 163 Association is ATM Address, if the Link Service Type is ATM Point-To- 164 Point, or ATM LIJ Call Identification, if the Link Service Type is 165 ATM MultiPoint-To-Point. See [5] for further details regarding the 166 ARA option. 168 A field similar to Opaque LSA could be easily defined for IS-IS. 169 Futher, it could be possible to use a well-known discretionary non- 170 transitive attribute of BGP to carry the address resolution 171 information, but the use of inter-domain routing protocols is outside 172 the scope of this document. 174 4. Discussion 176 The method proposed in this document allows efficient interconnection 177 of a set of routers over a legacy ATM network. After small amount of 178 manual configuration, the routers will automatically optimize direct 179 connectivity among themselves based on dynamic traffic load. Network 180 administrators can control the number of ATM VCs created by the 181 method taking into account scalability and cost. 183 As shown above, the method can readily exploit a multipoint-to-point 184 ATM signalling capability, which will reduce the number of ATM VCs 185 terminating at the destination routers. The method also benefits 186 from the capability to dynamically renegotiate the traffic parameters 187 of active ATM VCs. Both of these new capabilities are currently 188 under study in the ATM Forum. 190 5. Security Considerations 192 Since the method described in this document allows data paths to be 193 established that bypass the normal hop-by-hop control path, the 194 location of any access filters should be decided carefully. To 195 ensure proper enforcement of filter policies, filters should be moved 196 to the edges of an area so that they may be applied on entry or exit 197 from the short-cut data path. 199 References 201 [1] Farinacci, D., Meyer, D., and Rekhter, Y., "Intra-LIS IP 202 multicast among routers over ATM using Sparse Mode PIM". 203 draft-ietf-ion-intralis-multicast-01.txt, August 1997. 205 [2] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation 206 Layer 5". RFC 1483, July 1993. 208 [3] Perez, M, et al., "ATM Signalling Support for IP over ATM". RFC 209 1755, February 1995. 211 [4] Maher, M, "ATM Signalling Support for IP over ATM - 212 UNI Signalling 4.0 Update". draft-ietf-ion-sig-uni4.0-04.txt, May 213 1997. 215 [5] Coltun, R. and Heinanen, J., "The OSPF Address Resolution 216 Advertisement Option". Internet Draft, November 1997. 218 Acknowledgements 220 I would like to thank Rob Coltun and Lou Berger of Fore Systems for 221 their comments on earlier versions of this document. 223 Author Information 225 Juha Heinanen 226 Telia Finland, Inc. 227 Myyrmaentie 2 228 01600 VANTAA 229 Finland 231 Phone +358 303 994 808 232 Email jh@telia.fi