idnits 2.17.1 draft-ietf-pppext-mmp-discovery-02.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-23) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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. ** 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. ** Expected the document's filename to be given on the first page, but didn't find any == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 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: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 1998) is 9475 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) == Outdated reference: A later version (-16) exists of draft-ietf-pppext-l2tp-08 Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Draft-ietf-pppext-mmp-discovery-02.txt G. Malkin/Bay Networks 3 May 1998 5 Multi-link Multi-node PPP 6 Bundle Discovery Protocol 8 Abstract 10 This document specifies a standard way for Multi-link PPP to operate 11 across multiple nodes. Both the mechanism by which the Bundle Head 12 is discovered and the PPP fragment encapsulation are specified. 14 Status of this Memo 16 This document is an Internet Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a "working 25 draft" or "work in progress." 27 To learn the current status of any Internet-Draft, please check the 28 file "1id-abstracts.txt" contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 It is intended that this document will be submitted to the IESG for 34 consideration as a standards document. Distribution of this document 35 is unlimited. 37 Acknowledgements 39 I would like to thank Joe Frazier for filling in some of the details 40 and reviewing this document. 42 1. Introduction 44 Multi-link PPP [MP] allows a dial-in user to open multiple PPP 45 connections to a given host. In general, this is done on an on- 46 demand basis. That is, a secondary link, or multiple secondary 47 links, are established when the data load on the primary link, and 48 any previously established secondary links, nears capacity. As the 49 load decreases, the secondary link(s) may be disconnected. 51 Many dial-in hosts which support multi-link PPP dial the same phone 52 number for all links. This implies that there exists a rotary at the 53 Point Of Presence (POP) which routes incoming calls to a bank of 54 modems. These may be physically independent modems connected to 55 Remote Access Server (RAS) and a rotary of analog phone lines, or a 56 RAS with internal modems connected to analog lines or a T1/E1 or 57 T3/E3 channel. In any case, a given RAS can only handle just so many 58 simultaneous connections. A typical POP may need to support hundreds 59 of connections, but no RAS today can handle that many. This creates 60 a problem when a user's primary PPP connection is established to one 61 RAS in a POP and a secondary connection is established to another. 62 This may occur because the first RAS has no available modems, or 63 because incoming calls are assigned to ports in a round-robin 64 fashion, for example, and the second call is simply assigned to 65 another RAS. 67 The solution to this problem is to provide a mechanism by which a RAS 68 can determine if a Multi-link PPP connection is a primary or 69 secondary and, if a secondary, where the Bundle Head (the process 70 within a RAS which reassembles the PPP fragments transmitted over the 71 primary and secondary links) resides. If the Bundle Head resides on 72 a different RAS, a protocol must be used to transfer the PPP 73 fragments to the RAS containing the Bundle Head so that the PPP frame 74 can be reassembled. 76 Section 2 of this document specifies the Discovery Mechanism. 77 Section 3 specifies the Transfer Protocol. Section 4 specifies the 78 configuration parameters needed for the Discovery Protocol. 80 2. Bundle Head Discovery Mechanism 82 When a user dials into a RAS and negotiates Multi-link PPP (MP) 83 during the Link Control Protocol (LCP) phase, the RAS must determine 84 which one of the following three cases exists: 86 1- This is the primary (first) link of the MP connection. In this 87 case, the RAS should create the Bundle Head. 89 2- This is a secondary link of the MP connection and the Bundle Head 90 resides on this RAS. In this case, the RAS should add the link to 91 the Bundle (standard MP). 93 3- This is a secondary link of the MP connection and the Bundle Head 94 resides on a different RAS. In this case, the RAS should 95 establish a path (see section 3) to the RAS that has the Bundle 96 Head, and use that path to transfer MP fragments. 98 In operation, a RAS will make the determination for case 2 first 99 (because it is the easiest and requires no communication with other 100 RASes. If the Bundle Head is not local, the Discovery Protocol is 101 used to determine where the Bundle Head is, if it exists at all. 103 2.1 Packet Format 105 See "IANA Considerations" (section 6) for UDP port number assignment. 107 A Discovery Message has the following format: 109 +------+------+------------+------+----======----+ 110 | type |length| random ID | hash | endpoint ID | 111 +------+------+------------+------+----======----+ 113 where: 115 type - 2 octets 117 Message type: 1-query, 2-response. 119 length - 2 octets 121 The length (in octets) of the endpoint ID. 123 Random ID - 4 octets 125 A random identifier generated by the RAS used to resolve 126 contention. See "Contention Handling" (section 2.4) for the use 127 of this field. 129 hash - 2 octets 131 The unsigned sum (modulo 2^16) of the unsigned octets of the 132 Endpoint ID. A value of zero indicates that no hash has been 133 generated. See "Endpoint Identifier Matching" (section 2.2) for 134 the use of this field. 136 endpoint ID - variable length 138 The endpoint identifier of the connection. From the discovery 139 protocol's point of view, this is an opaque value. However, to 140 ensure multi-vendor interoperability, the format of this field 141 must be defined. The descriptions of, and legal values for, the 142 fields in the endpoint ID are defined in [MP]. 144 +------+------+--==--+------+------+--==--+------+--==--+ 145 |remote|remote|remote|local |local |local |user | user | 146 |EPD |EPD |EPD |EPD |EPD |EPD |name | name | 147 |class |length|data |class |length|data |length| data | 148 +------+------+--==--+------+------+--==--+------+--==--+ 150 Notes: 151 EPD = EndPoint Descriminator. 152 remote = dial-in host. 153 local = RAS. 154 class and length fields are 1-octet in length. 155 data fields are of variable (including zero) length. 157 The MP protocol requires that the RASes all have the same Local EPD. 158 For MMP, this implies that a RAS may not use its IP or Ethernet 159 address as an EPD. This also implies that all RASes on a rotary must 160 have the same EPD. RASes on different rotaries may share different 161 EPDs. The Local EPD is included in the endpoint identifier to ensure 162 that RASes on different rotaries, but sharing a common Ethernet, will 163 not join a particular discovery if the Remote EPDs just happen to be 164 the same. 166 Except for unicast Response Messages, all messages are sent to the 167 multicast address specified in "IANA Considerations". If a system 168 cannot send multicast messages, the limited broadcast address 169 (255.255.255.255) should be used. 171 2.2 Endpoint Identifier Matching 173 Comparing Endpoint IDs can be time consuming. First, the classes of 174 the EPDs must be determined, then the values compared. These 175 comparisons might be fast arithmetic compares or slow octet-wise 176 compares of 20-octet long values. To improve performance, because 177 the protocol is time-driven, the hash field may be used for a fast 178 comparison. 180 When a Bundle Head is created, the hash is created and stored along 181 with the Endpoint ID. When a Query or Response Message is generated, 182 the hash is created and stored in the message. When a RAS receives a 183 message, it can do a quick comparison of the hash in the message to 184 the hashes in its tables. If a hash does not match, the Endpoint ID 185 cannot match. However, if a hash does match, the Endpoint IDs must 186 be properly compared to verify the match. 188 Obviously, there is a cost associated with creating the hashes, but 189 they are created only once per message and once for each Bundle Head 190 creation. However, the comparisons occur multiple times in multiple 191 RASes for each new secondary connection. Therefore, there is a net 192 savings in processing. 194 2.3 Protocol Operation 196 Throughout this section, configurable variables are specified by 197 their names (e.g., ROBUSTNESS refers to the number of transmits). 199 The Discovery Protocol begins by multicasting ROBUSTNESS Query 200 Messages at QUERY_INTERVAL intervals. If no Response Message for 201 that Request is received within QUERY_INTERVAL of the last broadcast 202 (a total time of ROBUSTNESS * QUERY_INTERVAL), the RAS assumes that 203 this is the primary link and begins to build the Bundle Head. It 204 then sends a multicast Response Message (in case another link comes 205 up after the time-out but before the Bundle Head is built). If a 206 Response Message is received (i.e., a Bundle Head exists on another 207 RAS), no additional Query Messages are sent and the RAS establishes a 208 path the RAS containing the Bundle Head. 210 If a RAS receives a Query Message for an MP connection for which it 211 has the Bundle Head, it sends a unicast Response Message to the 212 querier. Note that no repetition of the Response Message is 213 necessary because, if it is lost, the querier's next query message 214 will trigger a new Response Message. 216 2.4 Contention Handling 218 If, while sending Query Messages, a Query Message for the same MP 219 connection is received, it indicates that the Dial-in Node has 220 brought up multiple links simultaneously. The resolution to this 221 contention is to elect the bundle head. To do this, each RAS waits 222 until all Query Messages are sent (ROBUSTNESS * QUERY_INTERVAL). At 223 that time, the RAS with the lowest Random ID becomes the Bundle Head. 224 If two or more RASes have the same Random ID, the RAS with the lowest 225 IP address becomes the Bundle Head. That RAS then sends TWO Response 226 Messages, with a QUERY_INTERVAL interval, and indicates to the MP 227 process that a Bundle Head should be formed. When the other RAS(es) 228 receive the Response Message, they cease broadcasting (if they 229 haven't already sent ROBUSTNESS Query Messages), stop listening for 230 additional Response Messages, and indicate to their respective MP 231 processes where the Bundle Head resides. 233 Note that a RAS generates a Random ID for each connection and uses 234 that value for all Query and Response messages associated with that 235 connection. The same Random ID must not be reused until it can be 236 guaranteed that another RAS will not mistake the message for an old 237 message from a previous connection. For this reason, it is 238 recommended that the Random ID be either monatomically increasing or 239 a clock value (either time since boot or time of day). 241 2.5 MP Operation 243 MP must use the following algorithm to ensure that there are no 244 windows of vulnerability during which multiple Bundle Heads might be 245 created for the same MP connection. 247 When an MP link is negotiated, MP first checks to see if it already 248 has the Bundle Head for this connection (i.e., is this a secondary 249 link). If it does, it should attach to it and not initiate a 250 discovery. As an optimization, if MP does not have a Bundle Head for 251 this connection, but does have a existing secondary link for it, MP 252 should attach to the known Bundle Head without initiating discovery. 254 If MP knows of no Bundle Head for this connection, it should initiate 255 a discovery. If the discovery should locate a Bundle Head, it should 256 attach to the indicated bundle head. If no Bundle Head is found, MP 257 should create a Bundle Head. 259 When a RAS determines that it is to become the Bundle Head for a 260 connection, it should establish the Bundle Head as quickly as 261 possible so Query Messages for that connection from other RASes will 262 be recognized. If a RAS indicates that it will become the Bundle 263 Head, but delays establishment of it, other RASes may time out on 264 their discovery and begin to establish additional Bundle Heads of 265 their own. 267 3. Transfer Protocol 269 The Layer 2 Tunneling Protocol (L2TP) [L2TP] will be used to transfer 270 PPP fragments from a RAS containing a secondary link to the RAS 271 containing the Bundle Head. By specifying the use of an existing 272 protocol, it is neither necessary to create nor implement a new 273 protocol. 275 4. Configuration 277 There are two required configuration switches and one conditional 278 configuration switch. None of the switches are optional. 280 4.1 Robustness - required 282 This switch sets the number of transmits (repetitions) for Query 283 Messages. It may be set between 1 and 15. The default is 3. Be 284 aware that lower settings may create windows of vulnerability. 285 Higher settings may cause MP timeouts, but may be needed on very 286 lossy or congested networks. 288 4.2 Query Interval - required 290 This switch sets the interval between Query Messages and the interval 291 between multicast Response Messages. It should be calibrated in 292 deciseconds (1/10 second) and may be set between 1 and 15. The 293 default is 1. Be aware that higher settings may cause MP timeouts, 294 but may be needed on very slow systems/networks. 296 4.3 TTL - conditional 298 This switch sets the IP Time-To-Live (TTL) of all Discovery packets. 299 For systems which are using the limited broadcast address, this 300 switch should not be implemented and the TTL should be set to 1. The 301 default value should be 1. 303 5. Security Considerations 305 No security is designed into the Discovery Mechanism. When not 306 forwarding multicast packets (or when using the limited broadcast 307 address), the discovery packets are restricted to a single LAN. If 308 the LAN is physically secure, there is no need for software security. 309 If the multicast packets are forwarded, but the range is limited to a 310 small, physically secure network (e.g., a POP), there is still no 311 need for software security. If the discovery packets are allowed to 312 cross an internet (and this is NOT recommended for timing reasons), 313 authentication of RASes may be done with IPSEC. For increased 314 security on a LAN, or in a POP, IPSEC may still be used. 316 L2TP security is discussed in [L2TP]. 318 6. IANA Considerations 320 UDP port number: 581 321 Multicast address: 224.0.1.69 323 7. References 325 [MP] "The PPP Multilink Protocol (MP)," K. Sklower, et al., RFC 326 1990, August 1996. 328 [L2TP] "Layer 2 Tunneling Protocol 'L2TP'," K. Hamzeh, et al., 329 draft-ietf-pppext-l2tp-08.txt, November 1997. 331 Author's Address 333 Gary Scott Malkin 334 Bay Networks 335 8 Federal Street 336 Billerica, MA 01821 338 Phone: +1 (978) 916-4237 339 Email: gmalkin@baynetworks.com