idnits 2.17.00 (12 Aug 2021) /tmp/idnits5857/draft-vasavada-pwe3-esp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 1) being 60 lines 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. ** The abstract seems to contain references ([RFC2661]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Both on the ingress and egress of the IP network, if there is any congestion in the direction of flow of traffic, the FECN bit MAY be set. If the FECN bit is already set, it SHOULD not be changed. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The D/E bit MAY be set at the ingress (when FR is encapsulated into ES) of the network if the traffic does not conform to the negotiated CIR/Be/Bc. If the D/E bit is already set, it SHOULD not be changed at the ingress of the IP network. The D/E bit SHOULD not changed at the egress of the IP network. -- 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 (July 2001) is 7615 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: 'TBD' is mentioned on line 545, but not defined == Unused Reference: 'RFC1661' is defined on line 1017, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1020, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'L2TPST' -- No information found for draft-ietf-l2tpext-ds - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'L2TPDS' -- Possible downref: Normative reference to a draft: ref. 'L2TPES' Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Nishit Vasavada 2 INTERNET DRAFT Amber Networks, Inc. 4 July 2001 6 ESP: Encapsulation Services Protocol 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 31 This document describes "Encapsulation Services (ES)" Protocol (ESP) 32 - the signaling and real-time transport protocol, suitable for 33 emulation of layer 1 and layer 2 circuits (e.g. FR, TDM, ATM and 34 private leased lines) over IP transport networks. 36 ESP provides end-to-end signaling mechanism suitable to establish ESP 37 tunnels and sessions over the underlying tunneling protocol. We 38 currently use Layer Two Tunneling Protocol (L2TP) as defined in 39 [RFC2661]. Other tunneling protocol may be extended in future to 40 support ESP. 42 Each emulated layer 1/2 circuit is encapsulated in an ES session 43 inside an ES tunnel. The ES session parameters comply with the 44 parameters of the parent ES tunnel. 46 1. Introduction 48 With service providers moving towards all new IP backbone networks, 49 there is a need to carry access technologies (e.g., Frame Relay, ATM) 50 over the IP backbone network. Most of these legacy access methods are 51 based on Layer 2 technologies. However, IP traditionally being a 52 Layer 3 protocol, the challenge is to carry Layer 2 traffic over this 53 IP backbone. 55 +----+ +------+ +===============+ +------+ +----+ 56 |FRAD|-------|Edge |--| IP/MPLS |--|Edge |--------|FRAD| 57 +----+ |Router| | NETWORK | |Router| +----+ 58 +------+ +===============+ +------+ 59 Frame Relay Core IP backbone Frame Relay 60 <-----------> <--------------------> <------------> 61 <---------Encapsulation Service------> 63 One such example is shown in the above figure where two Frame Relay 64 Access Devices (FRADs) are connected through an IP backbone. Private 65 Frame Relay networks can also be attached to each other in similar 66 fashion. ESP running on the edge router carries the Frame relay link 67 across the IP/MPLS backbone network to the remote end in a 68 transparent way. ESP emulates the characteristics specific to Frame 69 Relay over the IP network and thus the FRADs at both ends think as if 70 they are connected either directly or through another Frame Relay 71 network. Such emulation method includes the signaling procedure 72 needed to establish the ES tunnels and sessions and then the control 73 protocol needed for the link quality monitoring and also the Frame 74 Relay specific control information propagation mechanisms (such as 75 LMI). 77 Today's enterprises also depend heavily over private lines, which 78 span across the globe. These private lines carry pure bit-streams, 79 which are never looked into by intermediate network nodes. Hence, 80 carrying these circuits across IP network requires a "Circuit 81 Emulation Service", in particular, "IP Circuit Emulation Service". 82 This is similar to ATM CES which is in use for several years now. 84 +----+ +------+ +===============+ +------+ +----+ 85 |CPE |-------|Edge |--| IP/MPLS |--|Edge |--------|CPE | 86 +----+ |Router| | NETWORK | |Router| +----+ 87 +------+ +===============+ +------+ 88 Private Line Core IP backbone Private Line 89 <-----------> <--------------------> <------------> 90 <---------Encapsulation Service-----> 92 In this case, Private Circuits are connected to the Edge Router. ES, 93 running on the edge Router performs "Circuit Emulation" over IP 94 network and carries the Private lines to remote end. In this case, 95 the emulation is more of a "Layer 1" circuit emulation. The control 96 protocol here needs to include mechanism to propagate layer 1 circuit 97 characteristics, such as Idle suppression and Alarm suppression. 99 Note that in case of Layer-1 private line emulation, the protocol 100 does not need both ends to have similar physical characteristics. On 101 one side, the customer can connect one DS1 of a channelized DS3 link, 102 whereas the customer on the other end can connect through a single 103 DS1 line. Yet information about idle-suppression and alarm status 104 etc. are semantically carried to the remote end. 106 1.1. Outline of rest of the document: 108 Section 2 defines the requirements of the protocol. Section 3 shows 109 a reference model using L2TP as the lower layer transport. Rest of 110 the document is within the context of this reference model. Section 111 4 provides an overview of the protocol, while Section 5 describes the 112 protocol operation in detail. Section 6 talks about the ES control 113 message formats. Section 7 goes into issues specific to the access 114 link being encapsulated. Appendix A discusses the signaling with 115 L2TP. 117 2. Requirements of the Protocol 119 2.1. Connection Identifiers 121 One important inherent feature of traditional Layer 2 technologies 122 are their connection-oriented nature. But, IP being traditionally 123 connectionless protocol, there is a need to preserve the connection 124 identifiers of the Layer 2 technologies across the IP network. More 125 specifically, for Frame Relay, the (de)multiplexing based on Data 126 Link Connection Identifier (DLCI) must be preserved at the remote 127 end. 129 2.2. Alarms 131 Each access technology has some kind of "Alarm" built into the 132 specification of the technology. Such information must be preserved 133 and carried across the IP network for successful emulation of the 134 same. Frame Relay, for example uses "Link Management Interface (LMI)" 135 to carry such information. ES must have mechanism to propagate such 136 information between two ends. 138 2.3. Quality of Service 140 QoS issues are not addressed in this draft. 142 2.4. Other requirements 144 Another requirement for this service is the mechanism for privacy, 145 secrecy, encryption, authentication etc. The mechanism to emulate the 146 private lines must also provide facilities to realize the privacy of 147 user data being transported over the public IP network. 149 3. Reference Model 151 An emerging area in the evolution of IP network is the area of 152 "Tunneling Protocols". More specifically, RFC 2661 describes a 153 "Layer 2 Tunneling Protocol" (L2TP) as a means to tunnel PPP traffic 154 over various network clouds. It is proposed to use L2TP as a generic 155 tunneling mechanism and build an "Encapsulation Services" protocol to 156 meet the requirements described in Section 2. 158 A reference model which can be used for ESP is shown below. However, 159 it is possible to use ES over any other tunneling mechanism in an 160 IP/MPLS network. Future work will focus on these issues. 162 +--------+--------+ +--------+--------+ 163 | |ES | | ES | | 164 | +--------+ +--------+ | 165 | |L2TP | |L2TP | | 166 | Layer +--------+ +--------+ Layer | 167 | |UDP | |UDP | | 168 | 2 +--------+ +-----------+ +--------+ 2 | 169 | | | | | | | | 170 |Protocol| IP | | | | IP |Protocol| 171 | | | |IP NETWORK | | | | 172 +--------+--------+ +-----------+ +--------+--------+ 173 ^ ^ ^ ^ ^ ^ 174 FR/TDM | | | | | |FR/TDM 175 ----------+ +-----------+ +---------+ +------ 176 Link Link 178 As shown in the diagram above, the access link is terminated and is 179 fed to ESP. An encapsulation scheme is defined (described later) for 180 this Layer 2 traffic. That, in turn, is encapsulated in L2TP/UDP/IP 181 stack and the resulting IP packet is sent across the IP network to 182 the remote end. 184 At the remote side, the ES/L2TP/UDP/IP encapsulation is removed and 185 the resulting packet is sent on the access link. 187 4. Encapsulation Services Protocol Overview 189 4.1. ES components 191 Encapsulation Services Protocol (ESP) consists of the following 192 components: 193 - ES tunnel signaling (only with lower layer - not on the wire) 194 - ES session signaling 195 - ES Data transport protocol 196 - ES Keep Alive Protocol 197 - ES Alarm propagation protocol 198 - ES Quality Report Protocol 200 4.2. Protocol Specification 202 ESP has two components - ES Tunnel and ES Session. 204 4.2.1. ES Session 206 An "ES Session" carries a single layer 1 or 2 connection through IP 207 network. 208 - In case of Frame Relay, a single DLCI corresponds to an ES session. 209 - In case of ATM, a single ATM VPI/VCI is carried in an ES session. 210 - In case of Layer 1 (TDM) circuits, an ES session carries the entire 211 circuit. 213 The primary objective of an ES session is to "emulate" the 214 characteristics of the circuit through the IP network. An ES session 215 performs the following: 217 - Performs necessary signaling for connecting the two circuits at the 218 two ends of the network (with the help of underlying transport) 219 - Exchanges and negotiates the circuit-related traffic parameters 220 between the two end points 221 - Carries "Service Data Units" (SDUs) for the circuit 222 - Propagates the "Alarm" and "OAM" information through the IP network 223 to the remote end 224 - Maintains the connectivity of the circuit through the IP network by 225 appropriate "keep-alive" mechanism 226 - Monitors, prepares and generates "Quality Report" for the session 227 in IP network 229 4.2.2. ES Tunnel 231 An "ES Tunnel" is an aggregation of "ES sessions" which share the 232 following: 234 - All sessions are between the same pair of IP hosts (tunnel/session 235 end points) 236 - All sessions are for identical access technology (FR/ATM/TDM) 237 - All sessions require similar service level treatment in the IP 238 network 240 The following 4-tuple identifies an ES tunnel: 242 - IP address of tunnel's remote endpoint: This would typically be a 243 loop-back interface IP address of the remote host, but any other 244 value MAY be provisioned. For the purpose of accepting an ES 245 tunnel, this provisioned value is checked against the IP address of 246 incoming request. 248 - Access link type (FR/ATM/TDM/any other defined in future): This is 249 an ASCII string - current recognized values are "FR", "ATM" and 250 "CES" (for TDM circuits). Future work may involve standardizing 251 values for various access link types. 253 - Service attributes: Service attributes are represented by an ASCII 254 string mutually agreed on by the two ends in an "out-of-band" way 255 or administratively. This parameter maps to a specific set of 256 attributes of the service. This may include, but is not restricted 257 to the level of service, customer information, or any other 258 attributes which may differentiate the traffic in this tunnel from 259 that in any other tunnel. An example of this string is 260 "customer_a_gold". 262 - DS value: ES conveys this value to the lower layer transport. 263 Currently this applies to L2TP, in the context of [L2TPDS]. The 264 value is used both for the control packets (CCDS AVP as defined in 265 [L2TPDS]) and session packet (SDS AVP is defined in [L2TPDS]). 267 4.3. ES header format and encapsulation 269 A generic header format is proposed to facilitate data transport of 270 all kinds of Layer 2 protocols. The header is on the similar lines 271 of the RTP header with extensions/modifications for Encapsulation 272 Services. There is a 16-bit IP like checksum for the ES header to 273 ensure correctness of sequence number and other header fields. 275 0 1 2 276 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 |Ver| Reserved |P|M|I|A| Packet Sequence Number | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Length | Reserved | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Reserved | Checksum | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Flags: 287 - Ver: Version number, set to 1 288 - Reserved: Set to 0 on transmit, ignored on receipt 289 - P - for PCRC: Action on the payload CRC error. Drop the packet if 290 PCRC bit is 1, do not drop if the bit is 0. Latter case is used 291 for CES. 292 - H = Idle bit mask present (currently set to 0) 293 - I = Idle on/off (currently set to 0). If set to one, it indicates 294 that an AIS was received from local subscriber link, and the far 295 side should play idle pattern on the DS3 line. 296 - A = Alarm state on/off (currently set to 0) 297 - Packet sequence number: Incremented for every ES packet for a given 298 connection. Using sequence number is optional. If Sequence numbers 299 are not used, then this is set to 0. However, they are needed to 300 reorder packets received out of order. The sequence number starts 301 from and wraps to 1, not 0 (since 0 has special meaning). 302 - Length: Length of the payload 303 - Checksum: Used for the header and is 16 bit IP style checksum. If 304 the checksum is wrong, the packet will be dropped. 305 - CRC (32 bits) for the entire header and payload (to take care of 306 FR/ATM encapsulation). CRC is not used for ES control PDUs. ES 307 control PDUs compute a checksum over the ES control portion of the 308 PDU as described in individual control message descriptions. 310 5. ES Protocol Operation 312 Like most other protocols, ESP is split in two parts - Control Plane 313 and Data Plane. 315 5.1. ESP Control Plane 317 Setting up a tunnel (if needed), sessions within and the maintenance 318 messages are within the Control Plane. There is no ES level message 319 for setting up tunnel (see 5.1 for more on tunnel set-up) - lower 320 layer transport signaling is used for this purpose. All the ES 321 session messages have the following format: 323 12 byte ES Header + ES Control Message 325 ES header is defined in section 4.3. ES control messages are defined 326 in section 6.4. A 16 bit IP style checksum ensures integrity of 327 control plane PDUs. 329 5.2. ESP Data Plane 331 Data plane carries the L1/L2 payload to the far end of the tunnel. 332 The ESP data plane PDUs have the following format: 334 12 byte ES Header + Encapsulated Payload [+ CRC] 336 0 1 2 337 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 |Ver| Reserved |P|M|I|A| Packet Sequence Number | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Length | Reserved | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Reserved | Checksum | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Payload.... 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | CRC (only non-CES payload) | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 The payload is encapsulated and a CRC is added for FR and ATM cases. 353 The access link type specific discussion on payload encapsulation is 354 in Section 7. 356 The CRC is a 32 bit field at the end of the ES data PDU, and is 357 computed over the entire ES header and payload. 359 Rest of the document will mainly focus on the control plane. 361 5.3. ES Tunnel Signaling 363 5.3.1. ES Tunnel setup 365 When a network operator intends to carry certain Layer 1 or 2 traffic 366 to a certain remote IP host, the operator sets up an ES tunnel first. 367 An ES tunnel is a logical tunnel. It utilizes the tunnel set up by 368 the underlying transport protocol, e.g. an L2TP tunnel. No ES 369 control packets are exchanged for setting up an ES tunnel. 371 ES requests the underlying transport layer to setup a tunnel. The 372 distribution of provisioning and tunnel acceptance work is 373 implementation dependent. More information on this can be found in 374 Appendix A. 376 The Service Access Point between ES and L2TP is left to the 377 implementation. A good value to use would be the local tunnel ID 378 assigned by L2TP. 380 On receiving an indication from ES to set up a tunnel, the L2TP on 381 local side initiates the tunnel set-up. This follows the normal 382 set-up procedure as outlined in [RFC2661] with following constraints: 384 - exchange ESP as a service type in the service capabilities AVP, as 385 defined in [L2TPST]. The M-bit is set for this AVP to 386 ensure the peer supports ESP. 387 - use the string consisting of access_type.service_attributes as the 388 hostname for the host name AVP 389 - DS value for the CCDS AVP as defined in [L2TPDS]. 391 The remote side L2TP either processes the request at L2TP layer, or 392 passes on this request to ES providing the same <4-tuple> about the 393 originating side ES. This depends on the implementation as outlined 394 in Appendix A. 396 5.3.2. ES Tunnel Tear-down 398 This includes the following cases - 400 - Based on configured policies, ES determines that an incoming tunnel 401 should not be accepted 402 - User intends to tear down an existing tunnel. 404 Either way, ES notifies the underlying L2TP to release the tunnel. 405 While doing so, it specifies the SAP agreed up on when setting up the 406 tunnel (please see above). An appropriate L2TP error code SHOULD be 407 passed to L2TP, which L2TP can use while tearing down the tunnel. 409 5.4. ES Session Signaling 411 When user wants to connect a specific layer-1 or layer-2 circuit 412 (referred to as "access circuits" in the rest of the document) with a 413 remote circuit (layer-1 or layer-2 respectively), ES uses the session 414 signaling mechanisms for this purpose. An ES session is part of an 415 ES tunnel. For ES session to be established, a corresponding tunnel 416 MUST already exist. 418 The session terminates on the specific access circuit on the remote 419 side. User on one side requests ES to setup an ES session between the 420 two access circuits. ES specifies the local and remote side "access 421 circuit identifiers" to L2TP while requesting to set up a session in 422 the tunnel. These circuit identifiers depend on the specific Layer-1 423 or Layer-2 protocol that is being carried as listed below: 425 - Access port/line number and DLCI value for Frame Relay 426 - Access port/line number and VPI/VCI values for ATM 427 - Access port/line number for TDM circuits coming into the box 429 On the remote end, L2TP supplies the same set of identifiers to ES. 430 ES decides whether to accept or reject such an incoming call, 431 depending upon actual provisioning of the access circuit or some 432 other local policy. 434 If it wants to accept the call, it indicates so to L2TP. Otherwise, 435 it indicates to L2TP to reject the call and indicates the "Cause and 436 Diagnostic" code for the same. 438 5.4.1. ES Session setup 440 The ESP session is transported by L2TP session PDUs. To set up an 441 ESP session, an L2TP session needs to be established first. L2TP 442 uses following attributes passed by ES while setting up the session. 444 5.4.1.1. Signaling parameter: End-Identifiers 446 The end identifiers are encoded in the End-Identifier AVP of L2TP 447 session set-up message. This field is a sequence of ASCII octets. ES 448 encodes this in a format (defined later) and supplies to L2TP. The ES 449 on the remote side decodes this to extract the appropriate access 450 circuit identifiers for the session. 452 The way the remote circuit ID is encoded depends on the access type. 453 For Frame Relay, both interface and DLCI information is needed. For 454 TDM circuits, only interface number is communicated. 456 5.4.1.2. Signaling parameter: Service Type 458 L2TP uses ES as the service type in the Service Type AVP while 459 setting up the session. If there is any problem in using ES as the 460 service type for the session, the session is torn down. 462 5.4.1.3 Signaling parameter: DS Value 464 DS value is same as the one used in tunnel set-up. L2TP uses it for 465 SDS AVP while setting up the session. 467 Once L2TP session is set up, ESP sets up a session. 469 5.4.1.2. Traffic parameter negotiation 471 After L2TP session gets established, ES on both sides exchanges the 472 access side traffic parameters with the other side. These parameters 473 are specific to the particular access link, carried in the session: 475 For Frame Relay circuits: 476 - Committed Information Rate (CIR) 477 - Committed Burst (Bc) 478 - Excess Burst (Be) 480 For TDM circuits: 481 - Packet Size 482 - Jitter 483 - Minimum queue depth 485 For ATM VCs: [TBD] 487 With the help of these signaling procedures, ES on both sides 488 performs necessary checks, such that ingress parameters on one side 489 matches the egress parameters on the remote side and vice-versa. 491 In case of a failure in such checks, ES drops the sessions with an 492 appropriate cause and diagnostics code. 494 5.4.3. Session Tear-down 496 When user no longer needs the session, ES exchanges a "Terminate PDU" 497 with the remote peer and then brings down the underlying ES session. 499 5.4.4. Cause and diagnostic codes 501 Currently ES follows the well-established codes for L2TP. Future 502 work may involve setting up special codes for ES use. 504 5.5. Alarm Propagation 506 ES provides a mechanism to propagate access side "alarm information" 507 to remote side. This ensures that the user at the CPE sees a virtual 508 end-to-end layer-1/layer-2 link extending from its premise to the 509 remote premise. 511 The exact semantics of the alarm is access-technology dependent. The 512 specific alarms for Frame Relay, TDM circuits and ATM VCs are 513 described below: 515 5.5.1. Frame Relay 517 Local Management Interface (LMI) is used to perform link management 518 on LMI links. LMI has mechanisms to convey status of individual DLCI 519 (known as "A-bit status") on a frame relay link. ES terminates the 520 LMI protocol in the box and translates the information into ES 521 control PDU. The far side re-translates the ES control PDU back into 522 LMI message. Thus, both the ES end-points need to participate in LMI 523 protocol. Thus, the A-bit information gets propagated end-to-end 524 through the IP network in a transparent manner. 526 A particular implementation can choose the frequency of such 527 information exchange. It can be tied to the receipt of A-bit status 528 messages on one end on the link or can be performed in certain 529 periodic interval. Configuration or signaling of this periodic 530 interval will be covered in a future version. 532 Alarms can also be propagated in bulk so that multiple individual 533 alarms do not have to be transported across the IP network. 535 5.5.2. TDM circuits 537 The alarm information for a TDM circuit depends on the type of line 538 being emulated, e.g.: DS1 or DS3. Whenever a line (DS1 or DS3) goes 539 into alarm, ES sends a message to the remote ES specifying the 540 session corresponding to the line. The remote side ES plays the 541 appropriate alarm-bit-pattern for the appropriate interface. 543 5.5.3. ATM VCC 545 [TBD] 547 5.6. Idle Suppression Protocol 549 When there is no traffic on a Layer-1 circuit, the line can be 550 carrying idle-pattern. In such a case, ES notifies the remote side 551 about the same. The remote device starts playing idle pattern on the 552 line. 554 5.7. Quality Report 556 ES provides a mechanism to monitor and provide feedback in terms of 557 "Link Quality Report" on a per-session basis. Such information is 558 collected/measured on the egress side of the session and is fed back 559 to the ingress side. Ingress side ES can take intelligent decisions 560 based on such information for building resiliency and robustness to 561 the service. It is optional on part of the egress equipment to 562 perform such measurement. It is also optional on part of the ingress 563 equipment to take any intelligent decision based on such information. 564 However, if egress equipment does measure and propagate the 565 information to the ingress side, then the ingress side equipment MUST 566 make it accessible to user. 568 The parameters included in such monitoring and measurements are: 570 - Packet Loss: It may not be possible to measure packet loss without 571 using the sequence numbers for each packet. 572 - Round Trip Delay (RTD): ES provides a special loop-back IP packet 573 which when implemented must be looped-back to the source with a 574 timestamp. This can be used to measure the round trip delay for a 575 packet on a session. 576 - Bandwidth: The instantaneous bandwidth observed on the egress side 577 can be measured for a Frame relay circuit. 578 - Jitter: The instantaneous jitter experienced on the egress side for 579 a TDM circuit emulation, can be fed back to the ingress side. 581 More work in this area will be done in near future. 583 5.8. Keep Alive Protocol 585 ES relies on L2TP's "Hello Protocol" to maintain the heart beat of 586 the tunnel. 588 6. ES Message formats 590 There are two classes of ES messages: 592 - One class contains three of the ES parameters that are signaled 593 using L2TP mechanisms: Service Capabilities, Service Type, DS and 594 End-Identifier 595 - The second class contains ES messages that are exchanged between 596 two ES peers as ES control packets (L2TP payload packets). 598 These messages are described below: 600 6.1. Service Capabilities and Service Type AVP (Signaled through L2TP) 601 The exchange of this information is beyond the scope of this 602 document. Please refer to [L2TPES]. 604 6.2. DS value (Signaled through L2TP) 606 The exchange of this information is beyond the scope of this 607 document. Please refer to [L2TPDS]. 609 6.3. Remote end identifier (Signaled through L2TP AVP End-Identifier) 611 [L2TPES] defines the format of the End-Identifier AVP, which is used 612 to identify the local and remote access connection identifiers at 613 either end of the L2TP tunnel. 615 6.4. ES Control messages 617 The ES control messages are modeled in the same way as the PPP LCP 618 control packets. There are four classes of control messages: 620 - Session Configuration messages: These are used to exchange the 621 access side connection parameters. 622 - Session Terminate messages: These are exchanges to gracefully tear 623 down the ES session (before actually tearing down the corresponding 624 L2TP session). 625 - Access Alarm propagation messages: These messages are used to 626 propagate access side alarm status information. Alarms from 627 multiple sessions can be clubbed together and the message can be 628 sent on a tunnel basis. 629 - Link Quality Report messages: These are exchanged to report link 630 quality reports. 632 Every ES message is "request-response" based. For every message, the 633 remote ES peer sends back an acknowledgement to the sending ES peer. 634 For sending multiple messages on the same session, ES uses a sliding 635 window protocol with window size "1". The sender has to make the 636 transmission of every packet reliable by starting a timer and 637 awaiting an acknowledgement. Each message contains a "PDU-Identifier" 638 which must be sent back in the response message by the remote peer. 639 The sender must match the "PDU-Identifier" in the response message to 640 that in the last sent message to validate a response message. 642 A summary of ES control message is shown below: 644 0 1 2 645 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Code |PDU-Identifier | data ... 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 ... | Payload Checksum | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 Code: The code field is one octet. It identifies the type of message 653 that is encoded. When an unknown code field is received, a 654 "Code Reject" message is generated. 656 The possible values of the "Code" field are: 658 0x0001: Configure Request 659 0x0002: Configure Acknowledgement 660 0x0003: Configure NAK (Negative Acknowledgement) 661 0x0004: Configure Reject 662 0x0005: Reserved 663 0x0006: Reserved 664 0x0007: Reserved 665 0x0008: Reserved 666 0x0009: Quality Report Message 667 0x000a: Terminate Request 668 0x000b: Terminate Acknowledgement 669 0x000c: Bulk Alarm Message 670 0x000d: Bulk Alarm Acknowledgement 672 PDU-Identifier: It is a one octet field. It is used to identify a 673 response message with a request message sent out earlier. When a 674 message with invalid identifier is received, it is silently 675 discarded. 677 The PDU-Identifier must be changed whenever a new Configure Request 678 is generated and sent to the remote side and whenever a valid reply 679 has been received from the remote peer. When a Configure-Request is 680 retransmitted because of timeout, the PDU-Identifier value MAY be 681 changed. When responding to a request, the PDU-Identifier MUT match 682 the value contained in the request being responded to. 684 Data: The data field may contain fixed or variable number of octets, 685 depending upon the type of message encoded (indicated by "code" 686 field) as well as the access type (FR, TDM...). For the messages that 687 can contain variable number of octets, the length is obtained from 688 the header of the ES PDU (described in Section: 4.3). 690 Payload checksum: This is a 16 byte IP style checksum on the payload 691 beginning the "Code" field. 693 6.4.1. Configure Request (ConfReq) 695 The ES Configure Request message contains the access side connection 696 parameters. For Frame Relay, the parameters encoded are: 697 - CIR in "Kilo-Bits-per-second" (4 octets) 698 - Bc in "number of Bytes" (4 octets) 699 - Be in "number of Bytes" (4 octets) 701 The Configure Request message format for Frame Relay is shown below: 703 0 1 2 3 704 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Code | Identifier | CIR | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | CIR | Bc | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Bc | Be | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Be | Payload Checksum | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 Code: 1 for ES Configure-Request 716 Identifier and FR related fields: As described above 718 For CES sessions, the parameters encoded are: 719 - Jitter in "10s of micro-seconds" (2 octets) 720 - Minimum Q-depth in "10s of micro-seconds" (2 octets) 721 - Packet Size 723 The Configure Request message format for CES sessions is shown below: 725 0 1 2 3 726 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Code | Identifier | Jitter | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Minimum Queue Depth | Packet Size | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Payload Checksum | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 Code: 1 for ES Configure-Request 737 Identifier and CES related fields: As described above 739 Upon receipt, the ES peer verifies that the requested parameters are 740 supported, and the proposed values are acceptable. If any parameter 741 is not acceptable, the parameter is included in the Configure Reject 742 message and returned to the sender of Configure Request message. If 743 a parameter is supported, but if the value is not acceptable, a 744 Configure NAK is sent to the sender of the Configure Request message. 745 The Configure NAK includes the parameters whose values proposed in 746 Configure Request is/are not acceptable, and offers an alternate 747 value for these parameters. 749 6.4.2. Configure Acknowledgement (ConfAck) 751 The receiver of a ConfReq message MUST send back a ConfAck to the 752 sender, if the parameters present in the message were agreeable with. 753 The format of the message is shown below: 755 0 1 2 3 756 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Code | Identifier | Data ... 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 ... | Payload Checksum | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 Code: 2 for Configure Acknowledgement 765 Identifier: As described above, this field is copied from the PDU 766 Identifier field in the Configure Request which this message is 767 acknowledging. 769 Data: This field is a byte by byte copy of the data portion of the 770 Configure Request which this message is acknowledging. 772 Upon receipt, the recipient of ConfAck MUST find the ConfReq it 773 sent based on the PDU Identifier in the received ConfReq. If no such 774 ConfReq was sent, the ConfAck is silently discarded. If the ConfReq 775 was found, the data portion of the sent ConfReq and received ConfAck 776 are compared. If they are identical, ES session goes in up state. 777 However, if they are not identical, another ConfReq is sent to the 778 peer. 780 Data: Byte to byte copy of Configure-Request 782 6.4.3. Configure NAK (ConfNAK) 784 If the values present in the Configure Request message are not 785 agreeable with, a "Configure NAK (Negative Acknowledgement)" message 786 must be sent back to sender of ConfReq. The format of this message 787 is shown below: 789 0 1 2 3 790 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Code | Identifier | Data ... 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 ... | Payload Checksum | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 Code: 3 for ConfNAK 799 Identifier: As described above, this field is copied from the PDU 800 Identifier field in the Configure Request which this message is 801 NAKing. 803 Data: This field contains the parameters whose values in ConfReq were 804 not agreeable to the recipient. The sender of ConfNAK proposes new 805 values for these parameters and sends the message back to the sender 806 of ConfReq. 808 Upon receipt, the recipient of ConfNAK MUST check the proposed 809 values against its own configuration. If the values proposed in 810 ConfNAK are acceptable, a new Configure Request message SHOULD be 811 sent with all the parameters (including the ones which were not NAKed 812 by the other side). The values of the parameters NAKed will be the 813 values proposed in ConfNAK, or any other value per the configuration. 815 6.4.4. Configure Reject 817 If any/all parameter(s) present in the Configure Request message are 818 not acceptable to the receiving side based on the configuration, a 819 "Configure Reject" message back to sender of ConfReq. The format of 820 this message is shown below: 822 0 1 2 3 823 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Code | Identifier | Data ... 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 ... | Payload Checksum | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 Code: 4 for ConfRej 832 Identifier: As described above, this field is copied from the PDU 833 Identifier field in the Configure Request which this message is 834 NAKing. 836 Data: This field contains the parameters in ConfReq which are not 837 supported by the receiving side. 839 Upon receipt, the recipient of ConfRej MUST check the parameters 840 not supported by the other side. If the local configuration permits 841 carrying out the session without those parameters, a new Configure 842 Request MUST be sent without the parameters mentioned in Configure 843 Reject. If the local configuration does not permit setting up a 844 session without these parameters, the local side MUST send a 845 Terminate Request to tear down the session. 847 6.4.5. ES Quality Report 849 The need of the Quality Report has been described in section 5.7. 850 This area has been marked for future work. 852 6.4.6. ES Terminate Request 854 ESP uses this message to terminate an existing session. No 855 additional information is exchanged in this message. The format of 856 this message is shown below: 858 0 1 2 3 859 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Code | Identifier | Payload Checksum | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 Code: 10 for TermReq 866 6.4.7. ES Terminate Ack 868 ESP uses this message to acknowledge a terminate request received 869 from the peer. No additional information is exchanged in this 870 message. After sending this message, the sending side SHOULD clean 871 up the ESP session and inform the lower layer about the session 872 termination. Similarly, the receiving side SHOULD clean up the ESP 873 session and inform the lower layer about the session termination. 874 The format of this message is shown below: 876 0 1 2 3 877 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Code | Identifier | Payload Checksum | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 Code: 11 for TermAck 884 6.4.8. ES Bulk Alarm Message 886 This message is used to aggregate alarms on multiple ES sessions. 887 The format of this message is shown below: 889 0 1 2 3 890 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Code | Identifier | Alarm Status | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Session ID 1 | ... 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 ... | Payload Checksum | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 Code: 12 for Bulk Alarm Message 901 Alarm Status: Two bytes - reflects the status of the alarm for the 902 sessions mentioned in this message 904 Session ID (one or more): The alarm status shows in the "Alarm 905 Status" field reflects the status of sessions whose IDs are mentioned 906 here. 908 6.4.9. ES Bulk Alarm Ack 910 This message is used to acknowledge Bulk Alarm Message. The format 911 of this message is shown below: 913 0 1 2 3 914 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Code | Identifier | Alarm Status | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Session ID 1 | ... 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 ... | Payload Checksum | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 Code: 13 for Bulk Alarm Response 925 Alarm Status: Two bytes - carries the same value as the one in Alarm 926 Status field of the Bulk Alarm Message being acknowledged 928 Session ID (one or more): These fields are copied from the Bulk Alarm 929 Message being acknowledged 931 7. Layer 2 related issues 933 7.1. Layer 2 type independent issues 935 7.1.1. Out of order packets 937 Due to the inherent connection-less nature of IP networks, packets 938 may arrive out of order at the end of the ES tunnel. If packet 939 buffering and reordering is desired, sequence numbers SHOULD be 940 utilized in the ES header. 942 7.1.2. Packet integrity 944 A 16 bit checksum over the ES header, and a 32 bit CRC over the 945 entire ES header and payload ensures packet integrity and error 946 detection. 948 7.1.3. Connection Multiplexing 950 This is provided by carrying multiple ES sessions on top of L2TP 951 sessions in a single L2TP tunnel. 953 7.2. FR specific issues 955 7.2.1. CIR, Be and Bc 957 Although not needed for FR PVC, ES allows these parameters to be 958 signaled to the far side. 960 7.2.2. FECN 962 Both on the ingress and egress of the IP network, if there is any 963 congestion in the direction of flow of traffic, the FECN bit MAY be 964 set. If the FECN bit is already set, it SHOULD not be changed. 966 7.2.3. BECN 968 BECN bit is not changed in the current version. Future work may 969 involve setting it if necessary. 971 7.2.4. D/E 973 The D/E bit MAY be set at the ingress (when FR is encapsulated into 974 ES) of the network if the traffic does not conform to the negotiated 975 CIR/Be/Bc. If the D/E bit is already set, it SHOULD not be changed 976 at the ingress of the IP network. The D/E bit SHOULD not changed at 977 the egress of the IP network. 979 7.2.5. Encapsulation 981 The entire FR packet including the header is encapsulated. CRC16 is 982 not included. 984 7.3. TDM circuits specific issues 986 TDM frames are encapsulated in entirety. 988 8. Security Considerations 990 All the underlying L2TP Security considerations remain, though no 991 'new' ones are introduced? 993 9. IANA Considerations 995 To be completed. 997 10. Intellectual Property Considerations 999 Amber Networks may seek patent or other intellectual property 1000 protection for some of all of the technologies disclosed in this 1001 document. If any standards arising from this document are or become 1002 protected by one or more patents assigned to Amber Networks, Amber 1003 intends to disclose those patents and license them on reasonable and 1004 non-discriminatory terms. 1006 11. Acknowledgments 1008 Many thanks to Himansu Sahu, Stanley Fong, Harisankar Mallath, Ravi 1009 Bhat, Imtiyaj Kaji and Chi Fai Ho for their help in reviewing this 1010 draft. 1012 12. References 1014 [RFC2661] Townsley, et. al., "Layer Two Tunneling Protocol "L2TP"", 1015 RFC 2661, February 1999. 1017 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1018 RFC 1661, July 1994. 1020 [RFC2119] Bradner S., "Key words for use in RFCs to Indicate 1021 Requirement Levels", BCP 14, RFC 2119, March 1997. 1023 [L2TPST]. McPherson D., Nanji S., "L2TP Service Type", Work in 1024 Progress, April 2001. 1026 [L2TPDS] Calhoun P., et. al., "L2TP Differentiated Services 1027 Extension", draft-ietf-l2tpext-ds-03.txt, Work in Progress, March 1028 2001. 1030 [L2TPES] Vasavada N., "Encapsulation Services Protocol Service Type 1031 for L2TP", draft-vasavada-l2tpext-es-svctype-00.txt, Work in 1032 Progress, June 2001. 1034 13. Author's Address 1036 Nishit Vasavada 1037 Amber Networks, Inc. 1038 48664 Milmont Drive 1039 Fremont, CA 94538 1040 Phone: +1 510.687.5200 1041 Email: nishit@ambernetworks.com 1043 Appendix A: ES Tunnel Signaling 1045 The document only defines what identifies an ES tunnel. The 1046 requirements are for a host, but the document does not restrict the 1047 implementation as to which layer (ESP or the transport layer under 1048 it - L2TP for now) the provisioning and signaling occurs, specially 1049 since ES tunnel is a logical tunnel and no message exchange takes 1050 place at ES level to set up a tunnel. 1052 An implementation is required to do the following: 1053 - ESP MUST provide the host name to L2TP. L2TP MUST use it for the 1054 host name AVP and other implementation specific details related to 1055 host name. L2TP MUST also use it to find other provisioned tunnel 1056 parameters if they are provisioned at L2TP layer (please see 1057 below). 1059 An implementation is free to choose the following: 1060 - Whether the tunnel is provisioned at the lower layer, or ES signals 1061 the tunnel parameters to the lower layer. These parameters include 1062 remote end IP address, host name and DS value to be used for tunnel 1063 and sessions within the tunnel. If the host name is provisioned at 1064 L2TP layer, it must conform to the ES needs of 1065 "access_link_type.service_attributes" format - e.g. 1066 "FR.customer_a_gold". 1067 - Whether the tunnel is accepted at L2TP layer, or ES layer. If it 1068 is accepted at ES layer, L2TP MUST confirm with ES whether the 1069 incoming tunnel request can be accepted. If the tunnel acceptance 1070 processing is done at ESP layer, and if ESP decides to not accept 1071 the request, ESP MUST pass to L2TP an appropriate error/cause code 1072 which L2TP can use to send out a StopCCN. 1073 - The source IP address in the received packet used MUST match the 1074 remote endpoint address as provisioned.