idnits 2.17.1 draft-ietf-pppext-mmp-discovery-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-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. == 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 6. IANA Considerations' ) ** 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 (January 1998) is 9595 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 (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 draft-ietf-pppext-mmp-discovery-01.txt G. Malkin/Bay Networks 3 January 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 Please check the I-D abstract listing contained in each Internet 28 Draft directory to learn the current status of this or any other 29 Internet Draft. 31 It is intended that this document will be submitted to the IESG for 32 consideration as a standards document. Distribution of this document 33 is unlimited. 35 Acknowledgements 37 I would like to thank Joe Frazier for filling in some of the details 38 and reviewing this document. 40 1. Introduction 42 Multi-link PPP [MP] allows a dial-in user to open multiple PPP 43 connections to a given host. In general, this is done on an on- 44 demand basis. That is, a secondary link, or multiple secondary 45 links, are established when the data load on the primary link, and 46 any previously established secondary links, nears capacity. As the 47 load decreases, the secondary link(s) may be disconnected. 49 Many dial-in hosts which support multi-link PPP dial the same phone 50 number for all links. This implies that there exists a rotary at the 51 Point Of Presence (POP) which routes incoming calls to a bank of 52 modems. These may be physically independent modems connected to 53 Remote Access Server (RAS) and a rotary of analog phone lines, or a 54 RAS with internal modems connected to analog lines or a T1/E1 or 55 T3/E3 channel. In any case, a given RAS can only handle just so many 56 simultaneous connections. A typical POP may need to support hundreds 57 of connections, but no RAS today can handle that many. This creates 58 a problem when a user's primary PPP connection is established to one 59 RAS in a POP and a secondary connection is established to another. 60 This may occur because the first RAS has no available modems, or 61 because incoming calls are assigned to ports in a round-robin 62 fashion, for example, and the second call is simply assigned to 63 another RAS. 65 The solution to this problem is to provide a mechanism by which a RAS 66 can determine if a Multi-link PPP connection is a primary or 67 secondary and, if a secondary, where the Bundle Head (the process 68 within a RAS which reassembles the PPP fragments transmitted over the 69 primary and secondary links) resides. If the Bundle Head resides on 70 a different RAS, a protocol must be used to transfer the PPP 71 fragments to the RAS containing the Bundle Head so that the PPP frame 72 can be reassembled. 74 Section 2 of this document specifies the Discovery Mechanism. 75 Section 3 specifies the Transfer Protocol. Section 4 specifies the 76 configuration parameters needed for the Discovery Protocol. 78 2. Bundle Head Discovery Mechanism 80 When a user dials into a RAS and negotiates Multi-link PPP (MP) 81 during the Link Control Protocol (LCP) phase, the RAS must determine 82 which one of the following three cases exists: 84 1- This is the primary (first) link of the MP connection. In this 85 case, the RAS should create the Bundle Head. 87 2- This is a secondary link of the MP connection and the Bundle Head 88 resides on this RAS. In this case, the RAS should add the link to 89 the Bundle (standard MP). 91 3- This is a secondary link of the MP connection and the Bundle Head 92 resides on a different RAS. In this case, the RAS should 93 establish a path (see section 3) to the RAS that has the Bundle 94 Head, and use that path to transfer MP fragments. 96 In operation, a RAS will make the determination for case 2 first 97 (because it is the easiest and requires no communication with other 98 RASes. If the Bundle Head is not local, the Discovery Protocol is 99 used to determine where the Bundle Head is, if it exists at all. 101 2.1 Packet Format 103 See "IANA Considerations" (section 6) for UDP port number assignment. 105 A Discovery Message has the following format: 107 +------+------+------------+------+----======----+ 108 | type |length| random ID | hash | endpoint ID | 109 +------+------+------------+------+----======----+ 111 where: 113 type - 2 octets 115 Message type: 1-query, 2-response. 117 length - 2 octets 119 The length (in octets) of the endpoint ID. 121 Random ID - 4 octets 123 A random identifier generated by the RAS used to resolve 124 contention. See "Contention Handling" (section 2.4) for the use 125 of this field. 127 hash - 2 octets 129 The unsigned sum (modulo 2^16) of the unsigned octets of the 130 Endpoint ID. A value of zero indicates that no hash has been 131 generated. See "Endpoint Identifier Matching" (section 2.2) for 132 the use of this field. 134 endpoint ID - variable length 136 The endpoint identifier of the connection. From the discovery 137 protocol's point of view, this is an opaque value. However, to 138 ensure multi-vendor interoperability, the format of this field 139 must be defined. The descriptions of, and legal values for, the 140 fields in the endpoint ID are defined in [MP]. 142 +------+------+--==--+------+------+--==--+------+--==--+ 143 |remote|remote|remote|local |local |local |user | user | 144 |EPD |EPD |EPD |EPD |EPD |EPD |name | name | 145 |class |length|data |class |length|data |length| data | 146 +------+------+--==--+------+------+--==--+------+--==--+ 148 Notes: 149 EPD = EndPoint Descriminator. 150 remote = dial-in host. 151 local = RAS. 152 class and length fields are 1-octet in length. 153 data fields are of variable (including zero) length. 155 2.2 Endpoint Identifier Matching 157 Comparing Endpoint IDs can be time consuming. First, the classes of 158 the EPDs must be determined, then the values compared. These 159 comparisons might be fast arithmetic compares or slow octet-wise 160 compares of 20-octet long values. To improve performance, because 161 the protocol is time-driven, the hash field may be used for a fast 162 comparison. 164 When a Bundle Head is created, the hash is created and stored along 165 with the Endpoint ID. When a Query or Response Message is generated, 166 the hash is created and stored in the message. When a RAS receives a 167 message, it can do a quick comparison of the hash in the message to 168 the hashes in its tables. If a hash does not match, the Endpoint ID 169 cannot match. However, if a hash does match, the Endpoint IDs must 170 be properly compared to verify the match. 172 Obviously, there is a cost associated with creating the hashes, but 173 they are created only once per message and once for each Bundle Head 174 creation. However, the comparisons occur multiple times in multiple 175 RASes for each new secondary connection. Therefore, there is a net 176 savings in processing. 178 2.3 Protocol Operation 180 Throughout this section, configurable variables are specified by 181 their names (e.g., ROBUSTNESS refers to the number of transmits). 183 The Discovery Protocol begins by sending to MULTICAST, ROBUSTNESS 184 Query Messages at QUERY_INTERVAL intervals. If no Response Message 185 for that Request is received within QUERY_INTERVAL of the last 186 broadcast (a total time of ROBUSTNESS * QUERY_INTERVAL), the RAS 187 assumes that this is the primary link and begins to build the Bundle 188 Head. It then sends to MULTICAST a Response Message (in case another 189 link comes up after the time-out but before the Bundle Head is 190 built). If a Response Message is received (i.e., a Bundle Head 191 exists on another RAS), no additional Query Messages are sent and the 192 RAS establishes a path the RAS containing the Bundle Head. 194 If a RAS receives a Query Message for an MP connection for which it 195 has the Bundle Head, it sends a unicast Response Message to the 196 querier. Note that no repetition of the Response Message is 197 necessary because, if it is lost, the querier's next query message 198 will trigger a new Response Message. 200 2.4 Contention Handling 202 If, while sending Query Messages, a Query Message for the same MP 203 connection is received, it indicates that the Dial-in Node has 204 brought up multiple links simultaneously. The resolution to this 205 contention is to elect the bundle head. To do this, each RAS waits 206 until all Query Messages have been sent (ROBUSTNESS * 207 QUERY_INTERVAL). At that time, the RAS with the lowest Random ID 208 becomes the Bundle Head. If two or more RASes have the same Random 209 ID, then the RAS with the lowest IP address becomes the Bundle Head. 210 That RAS then sends TWO response messages, with a QUERY_INTERVAL 211 interval, and indicates to the MP process that a Bundle Head should 212 be formed. When the other RAS(es) receive the Response Message, they 213 cease broadcasting (if they haven't already sent all ROBUSTNESS Query 214 Messages), stop listening for additional Response Messages, and 215 indicate to their respective MP processes where the Bundle Head 216 resides. 218 2.5 MP Operation 220 MP must use the following algorithm to ensure that there are no 221 windows of vulnerability during which multiple Bundle Heads might be 222 created for the same MP connection. 224 When an MP link is negotiated, MP first checks to see if it already 225 has the Bundle Head for this connection (i.e., is this a secondary 226 link). If it does, it should attach to it and not initiate a 227 discovery. As an optimization, if MP does not have a Bundle Head for 228 this connection, but does have a existing secondary link for it, MP 229 should attach to the known Bundle Head without initiating discovery. 231 If MP knows of no Bundle Head for this connection, it should initiate 232 a discovery. If the discovery should locate a Bundle Head, it should 233 attach to the indicated bundle head. If no Bundle Head is found, MP 234 should create a Bundle Head. 236 3. Transfer Protocol 238 The Layer 2 Tunneling Protocol (L2TP) [L2TP] will be used to transfer 239 PPP fragments from a RAS containing a secondary link to the RAS 240 containing the Bundle Head. By specifying the use of an existing 241 protocol, it is neither necessary to create nor implement a new 242 protocol. 244 4. Configuration 246 There are two required configuration switches and two conditional 247 configuration switches. None of the switches are optional. 249 4.1 Robustness - required 251 This switch sets the number of transmits (repetitions) for Query 252 Messages. It may be set between 1 and 15. The default is 3. Be 253 aware that lower settings may create windows of vulnerability. 254 Higher settings may cause MP timeouts, but may be needed on very 255 lossy or congested networks. 257 4.2 Query Interval - required 259 This switch sets the interval between Query Messages and the interval 260 between MULTICAST Response Messages. It should be calibrated in 261 deciseconds (1/10 second) and may be set between 1 and 15. The 262 default is 1. Be aware that higher settings may cause MP timeouts, 263 but may be needed on very slow systems/networks. 265 4.3 Multicast - conditional 267 This switch selects between the use of the forwardable and 268 nonforwardable IP multicast addresses for the Discovery Mechanism. 269 For systems which do not support IP multicast, and therefore use the 270 limited broadcast address, this switch should not be implemented. 271 The default value should be nonforwardable. See "IANA 272 Considerations" (section 6) for multicast address assignments. 274 4.4 TTL - conditional 276 This switch sets the IP Time-To-Live (TTL) of all Discovery packets. 277 For systems which are using the limited broadcast address, this 278 switch should not be implemented and the TTL should be set to 1. The 279 default value should be 1. 281 5. Security Considerations 283 No security is designed into the Discovery Mechanism. When using the 284 non-forwardable multicast address (or limited broadcast address), the 285 discovery packets are restricted to a single LAN. If the LAN is 286 physically secure, there is no need for software security. If the 287 forwardable multicast address is used, but the range is limited to a 288 small, physically secure network (e.g., a POP), there is still no 289 need for software security. If the discovery packets are allowed to 290 cross an internet (and this is NOT recommended for timing reasons), 291 authentication of RASes may be done with IPSEC. For increased 292 security on a LAN, or in a POP, IPSEC may still be used. 294 L2TP security is discussed in [L2TP]. 296 6. IANA Considerations 298 UDP port number: 581 299 Forwardable multicast address: TBA 300 Non-forwardable multicast address: TBA 302 7. References 304 [MP] "The PPP Multilink Protocol (MP)," K. Sklower, et al., RFC 305 1990, August 1996. 307 [L2TP] "Layer 2 Tunneling Protocol 'L2TP'," K. Hamzeh, et al., 308 draft-ietf-pppext-l2tp-08.txt, November 1997. 310 Author's Address 312 Gary Scott Malkin 313 Bay Networks 314 8 Federal Street 315 Billerica, MA 01821 317 Phone: +1 (978) 916-4237 318 Email: gmalkin@baynetworks.com