idnits 2.17.1 draft-ietf-pppext-mmp-discovery-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-18) 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 9651 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: 10 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-00.txt G. Malkin/Bay Networks 3 November 1997 5 Multi-link Multi-node PPP 7 Abstract 9 This document specifies a standard way for Multi-link PPP to operate 10 across multiple nodes. Both the mechanism by which the Bundle Head 11 is discovered and the PPP fragment encapsulation are specified. 13 Status of this Memo 15 This document is an Internet Draft. Internet Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its Areas, 17 and its Working Groups. Note that other groups may also distribute 18 working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet 23 Drafts as reference material or to cite them other than as a "working 24 draft" or "work in progress." 26 Please check the I-D abstract listing contained in each Internet 27 Draft directory to learn the current status of this or any other 28 Internet Draft. 30 It is intended that this document will be submitted to the IESG for 31 consideration as a standards document. Distribution of this document 32 is unlimited. 34 Acknowledgements 36 I would like to thank Joe Frazier for filling in some of the details 37 and reviewing this document. 39 1. Introduction 41 Multi-link PPP [MP] allows a dial-in user to open multiple PPP 42 connections to a given host. In general, this is done on an on- 43 demand basis. That is, a secondary link, or multiple secondary 44 links, are established when the data load on the primary link, and 45 any previously established secondary links, nears capacity. As the 46 load decreases, the secondary link(s) may be disconnected. 48 Many dial-in hosts which support multi-link PPP dial the same phone 49 number for all links. This implies that there exists a rotary at the 50 Point Of Presence (POP) which routes incoming calls to a bank of 51 modems. These may be physically independent modems connected to 52 Remote Access Server (RAS) and a rotary of analog phone lines, or a 53 RAS with internal modems connected to analog lines or a T1/E1 or 54 T3/E3 channel. In any case, a given RAS can only handle just so many 55 simultaneous connections. A typical POP may need to support hundreds 56 of connections, but no RAS today can handle that many. This creates 57 a problem when a user's primary PPP connection is established to one 58 RAS in a POP and a secondary connection is established to another. 59 This may occur because the first RAS has no available modems, or 60 because incoming calls are assigned to ports in a round-robin 61 fashion, for example, and the second call is simply assigned to 62 another RAS. 64 The solution to this problem is to provide a mechanism by which a RAS 65 can determine if a Multi-link PPP connection is a primary or 66 secondary and, if a secondary, where the Bundle Head (the process 67 within a RAS which reassembles the PPP fragments transmitted over the 68 primary and secondary links) resides. If the Bundle Head resides on 69 a different RAS, a protocol must be used to transfer the PPP 70 fragments to the RAS containing the Bundle Head so that the PPP frame 71 can be reassembled. 73 Section 2 of this document specifies the Discovery Mechanism. 74 Section 3 specifies the Transfer Protocol. Section 4 specifies the 75 configuration parameters needed for the Discovery Protocol. 77 2. Bundle Head Discovery Mechanism 79 When a user dials into a RAS and negotiates Multi-link PPP (MP) 80 during the Link Control Protocol (LCP) phase, the RAS must determine 81 which one of the following three cases exists: 83 1- This is the primary (first) link of the MP connection. In this 84 case, the RAS should create the Bundle Head. 86 2- This is a secondary link of the MP connection and the Bundle Head 87 resides on this RAS. In this case, the RAS should add the link to 88 the Bundle (standard MP). 90 3- This is a secondary link of the MP connection and the Bundle Head 91 resides on a different RAS. In this case, the RAS should 92 establish a path (see section 3) to the RAS that has the Bundle 93 Head, and use that path to transfer MP fragments. 95 In operation, a RAS will make the determination for case 2 first 96 (because it is the easiest and requires no communication with other 97 RASes. If the Bundle Head is not local, the Discovery Protocol is 98 used to determine where the Bundle Head is, if it exists at all. 100 2.1 Packet Format 102 See "IANA Considerations" (section 6) for UDP port number assignment. 104 A Discovery Message has the following format: 106 +------+------+------------+----------+----======----+ 107 | type |length| IP address | checksum | endpoint ID | 108 +------+------+------------+----------+----======----+ 110 where: 112 type - 1 octet 114 Message type: 1-query, 2-response. 116 length - 1 octet 118 The length (in octets) of the endpoint ID. 120 IP address - 4 octets 122 The IP address of the RAS transmitting the message. 124 checksum - 2 octets 126 The ones-complement checksum of the endpoint ID. This is the 127 standard IP checksum except that the checksum is not self- 128 inclusive (i.e., the checksum is done only over the endpoint ID). 129 A value of zero indicates that no checksum has been generated. 130 See "Endpoint Identifier Matching" (section 2.2) for the use of 131 this field. 133 endpoint ID - variable length 135 The endpoint identifier of the connection. From the discovery 136 protocol's point of view, this is an opaque value. However, to 137 ensure multi-vendor interoperability, the format of this field 138 must be defined. The descriptions of, and legal values for, the 139 fields in the endpoint ID are defined in [MP]. 141 +------+------+--==--+------+------+--==--+------+--==--+ 142 |remote|remote|remote|local |local |local |user | user | 143 |EPD |EPD |EPD |EPD |EPD |EPD |name | name | 144 |class |length|data |class |length|data |length| data | 145 +------+------+--==--+------+------+--==--+------+--==--+ 147 Notes: 148 EPD = EndPoint Descriminator. 149 remote = dial-in host. 150 local = RAS. 151 class and length fields are 1-octet in length. 152 data fields are of variable (including zero) length. 154 2.2 Endpoint Identifier Matching 156 Comparing endpoint IDs can be time consuming. First, the classes of 157 the EPDs must be determined, then the values compared. These 158 comparisons might be fast arithmetic compares or slow octet-wise 159 compares of 20-octet long values. To improve performance, because 160 the protocol is time-driven, the checksum field may be used for a 161 fast comparison. 163 When a Bundle Head is created, the checksum is created and stored 164 along with the Endpoint ID. When a Query or Response Message is 165 generated, the checksum is created and stored in the message. When a 166 RAS receives a message, it can do a quick comparison of the checksum 167 in the message to the checksums in its tables. If a checksum does 168 not match, the Endpoint ID cannot match. However, if a checksum does 169 match, the Endpoint IDs must be properly compared to verify the 170 match. 172 Obviously, there is a cost associated with creating the checksums, 173 but they are created only once per message and once for each Bundle 174 Head creation. However, the comparisons occur multiple times in 175 multiple RASes for each new secondary connection. Therefore, there 176 is a net 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 IP address, 208 as taken from the Query Message, becomes the Bundle Head. That RAS 209 then sends TWO response messages, with a QUERY_INTERVAL interval, and 210 indicates to the MP process that a Bundle Head should be formed. 211 When the other RAS(es) receive the Response Message, they cease 212 broadcasting (if they haven't already sent all ROBUSTNESS Query 213 Messages), stop listening for additional Response Messages, and 214 indicate to their respective MP processes where the Bundle Head 215 resides. 217 2.5 MP Operation 219 MP must use the following algorithm to ensure that there are no 220 windows of vulnerability during which multiple Bundle Heads might be 221 created for the same MP connection. 223 When an MP link is negotiated, MP first checks to see if it already 224 has the Bundle Head for this connection (i.e., is this a secondary 225 link). If it does, it should attach to it and not initiate a 226 discovery. As an optimization, if MP does not have a Bundle Head for 227 this connection, but does have a existing secondary link for it, MP 228 should attach to the known Bundle Head without initiating discovery. 230 If MP knows of no Bundle Head for this connection, it should initiate 231 a discovery. If the discovery should locate a Bundle Head, it should 232 attach to the indicated bundle head. If no Bundle Head is found, MP 233 should create a Bundle Head. 235 3. Transfer Protocol 237 The Layer 2 Tunneling Protocol (L2TP) [L2TP] will be used to transfer 238 PPP fragments from a RAS containing a secondary link to the RAS 239 containing the Bundle Head. By specifying the use of an existing 240 protocol, it is neither necessary to create nor implement a new 241 protocol. 243 4. Configuration 245 There are two required configuration switches and two conditional 246 configuration switches. None of the switches are optional. 248 4.1 Robustness - required 250 This switch sets the number of transmits (repetitions) for Query 251 Messages. It may be set between 1 and 15. The default is 3. Be 252 aware that lower settings may create windows of vulnerability. 253 Higher settings may cause MP timeouts, but may be needed on very 254 lossy or congested networks. 256 4.2 Query Interval - required 258 This switch sets the interval between Query Messages and the interval 259 between MULTICAST Response Messages. It should be calibrated in 260 deciseconds (1/10 second) and may be set between 1 and 15. The 261 default is 1. Be aware that higher settings may cause MP timeouts, 262 but may be needed on very slow systems/networks. 264 4.3 Multicast - conditional 266 This switch selects between the use of the forwardable and 267 nonforwardable IP multicast addresses for the Discovery Mechanism. 268 For systems which do not support IP multicast, and therefore use the 269 limited broadcast address, this switch should not be implemented. 270 The default value should be nonforwardable. See "IANA 271 Considerations" (section 6) for multicast address assignments. 273 4.4 TTL - conditional 275 This switch sets the IP Time-To-Live (TTL) of all Discovery packets. 276 For systems which are using the limited broadcast address, this 277 switch should not be implemented and the TTL should be set to 1. The 278 default value should be 1. 280 5. Security Considerations 282 No security is designed into the Discovery Mechanism. When using the 283 non-forwardable multicast address (or limited broadcast address), the 284 discovery packets are restricted to a single LAN. If the LAN is 285 physically secure, there is no need for software security. If the 286 forwardable multicast address is used, but the range is limited to a 287 small, physically secure network (e.g., a POP), there is still no 288 need for software security. If the discovery packets are allowed to 289 cross an internet (and this is NOT recommended for timing reasons), 290 authentication of RASes may be done with IPSEC. For increased 291 security on a LAN or in a POP, IPSEC may still be used. 293 L2TP security is discussed in [L2TP]. 295 6. IANA Considerations 297 UDP port number: 581 298 Forwardable multicast address: TBA 299 Non-forwardable multicast address: TBA 301 7. References 303 [MP] "The PPP Multilink Protocol (MP)," K. Sklower, et al., RFC 304 1990, August 1996. 306 [L2TP] "Layer 2 Tunneling Protocol 'L2TP'," K. Hamzeh, et al., 307 draft-ietf-pppext-l2tp-08.txt, November 1997. 309 Author's Address 311 Gary Scott Malkin 312 Bay Networks 313 8 Federal Street 314 Billerica, MA 01821 316 Phone: +1 (978) 916-4237 317 Email: gmalkin@baynetworks.com