idnits 2.17.1 draft-ietf-l2tpext-mcast-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1226. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 2004) is 7132 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC3590' is mentioned on line 161, but not defined == Unused Reference: 'RFC1661' is defined on line 1043, but no explicit reference was found in the text Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Bourdon 3 Internet Draft France Telecom 4 Document: draft-ietf-l2tpext-mcast-05.txt October 2004 5 Category: Experimental 7 Extensions to support efficient carrying of 8 multicast traffic in Layer-2 Tunneling Protocol (L2TP) 9 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The Layer Two Tunneling Protocol (L2TP) provides a standard method 36 for tunneling PPP packets. This document describes an extension to 37 L2TP, in order to have an efficient use of L2TP tunnels within the 38 context of deploying multicast services whose data will have to be 39 conveyed by such tunnels. 41 Table of Contents 43 1. Introduction................................................2 44 1.1. Conventions used in this document...........................3 45 1.2. Terminology.................................................3 46 2. Motivation for a session-based solution.....................4 47 3. Control Connection establishment............................5 48 3.1. Negotiation phase...........................................5 49 3.2. Multicast Capability AVP (SCCRQ, SCCRP).....................5 50 4. L2TP multicast session establishment decision...............6 51 4.1. Multicast states in LNS.....................................6 52 4.2. Group state determination...................................7 53 4.3. Triggering..................................................8 54 4.4. Multicast traffic sent from group members...................9 55 5. L2TP multicast session opening process.....................10 56 5.1. Multicast-Session-Request (MSRQ)...........................10 57 5.2. Multicast-Session-Response (MSRP)..........................11 58 5.3. Multicast-Session-Established (MSE)........................12 59 6. Session maintenance and management.........................12 60 6.1. Multicast-Session-Information (MSI)........................12 61 6.2. Outgoing Sessions List updates.............................13 62 6.2.1. New Outgoing Sessions AVP (MSI)............................13 63 6.2.2. New Outgoing Sessions Acknowledgement AVP (MSI)............14 64 6.2.3. Withdraw Outgoing Sessions AVP (MSI).......................15 65 6.3. Multicast Packets Priority AVP (MSI).......................16 66 6.3.1. Global configuration.......................................17 67 6.3.2. Individual configuration...................................17 68 6.3.3. Priority...................................................17 69 7. Multicast session teardown.................................18 70 7.1. Operations.................................................18 71 7.2. Multicast-Session-End-Notify (MSEN)........................19 72 7.3. Result Codes...............................................19 73 8. Traffic merging............................................20 74 9. IANA Considerations........................................20 75 10. Security Considerations....................................21 76 11. References.................................................21 77 11.1. Normative References.......................................21 78 11.2. Informative References.....................................22 79 12. Acknowledgments............................................22 80 13. Author's Addresses.........................................22 81 Appendix A. Examples of group states determination................23 83 1. Introduction 85 The deployment of IP multicast-based services may have to deal with 86 L2TP tunnel engineering. From this perspective, the forwarding of 87 multicast data within L2TP sessions may impact the throughput of L2TP 88 tunnels because the same traffic may be sent multiple times within 89 the same L2TP tunnel, but in different sessions. This proposal aims 90 to reduce this impact by applying replication mechanism of multicast 91 traffic only when necessary. 92 The solution described herein provides a mechanism for transmitting 93 multicast data only once for all the L2TP sessions that have been 94 established in a tunnel, each multicast flow having a dedicated L2TP 95 session. 96 Within the context of deploying IP multicast-based services, it is 97 assumed that the routers of the IP network that embed a L2TP Network 98 Server (LNS) capability may be involved in the forwarding of 99 multicast data, towards users who access the network through an L2TP 100 tunnel. Then the LNS is in charge of replicating the multicast data 101 for each L2TP session that is used by a receiver who has requested a 102 multicast flow. The solution described here gives the ability for a 103 LNS to send multicast data only once and let the L2TP Access 104 Concentrator (LAC) perform the traffic replication. By doing so, it 105 is expected to spare transmission resources in the core network that 106 supports L2TP tunnels. This multicast extension to L2TP is designed 107 so that it does not affect the behavior of L2TP equipment under 108 normal conditions. A solution to carry multicast data only once in a 109 L2TP tunnel is interesting for service providers since edge devices 110 are aggregating more and more users. This is particularly true for 111 operators who are deploying xDSL (Digital Subscriber Line) services 112 and cable infrastructures. Therefore, L2TP tunnels that may be 113 supported by the network will have to carry multiple redundant 114 multicast data more often. The solution described in this document 115 applies to downstream traffic exclusively, i.e. data coming from the 116 LNS towards end-users connected to the LAC. This downstream multicast 117 traffic is not framed by the LNS but by the LAC, thus ensuring 118 compatibility for all users in a common tunnel whatever the framing 119 scheme. 121 1.1. Conventions used in this document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 1.2. Terminology 129 Unicast session 131 This term refers to the definition of "Session", as it is described 132 in the terminology section of [RFC2661]. (Also: L2TP unicast session) 134 Multicast session 136 This term refers to a connection between the LAC and the LNS. 137 Additional Control Messages and Attribute-Value-Pairs (AVPs) are 138 defined in this document to open and maintain this connection for the 139 particular purpose of multicast traffic transportation. This 140 connection between the LAC and the LNS is intended to convey 141 multicast traffic only. (Also: L2TP multicast session) 143 Session 145 This term is used when there is no need to dissociate multicast from 146 unicast sessions, and thus designates both. (Also: L2TP session) 148 M-IGP 149 Designates a Multicast Interior Gateway Protocol. 151 Multicast flow 153 Designates datagrams sent to a group from a set of sources for which 154 multicast reception is desired. 156 GMP 158 Group Management Protocol, such as: 159 - IGMPv1 ([RFC1112]) 160 - IGMPv2 ([RFC2236]) 161 - MLD ([RFC2710], [RFC3590]) 163 SFGMP 165 Source Filtering Group Management Protocol such as: 166 - IGMPv3 ([RFC3376]) 167 - MLDv2 ([RFC3810]) 169 2. Motivation for a session-based solution 171 Multicast data have to be seen as a singular flow that may be 172 conveyed into all the L2TP sessions that have been established in a 173 tunnel. It means that a given L2TP session can be dedicated for the 174 forwarding of a multicast flow that will be forwarded to multiple 175 receivers, including those that can be reached by one or several of 176 these L2TP sessions. A session carrying IP multicast data is 177 independent from the underlying framing scheme and is therefore 178 compatible with any new framing scheme that may be supported by the 179 L2TP protocol. 181 Using a single L2TP session per multicast flow is motivated by the 182 following arguments: 184 - The administrator of the LNS is presumably in charge of the IP 185 multicast-based services and the related engineering aspects. As 186 such, he must be capable of filtering multicast traffic on a 187 multicast source basis, on a multicast group basis, and/or on a user 188 basis (users who access the network using a L2TP session that 189 terminates in this LNS). 190 - Having a L2TP session dedicated for a multicast flow gives the 191 ability to enforce specific policies for multicast traffic. For 192 instance, it is possible to change the priority treatment for 193 multicast packets against unicast packets. 194 - It is not always acceptable nor possible to have multicast 195 forwarding performed within the network between the LAC and the LNS. 196 Having the multicast traffic conveyed within a L2TP tunnel ensures a 197 multicast service between the LNS and end-users, alleviating the need 198 for activating multicast capabilities in the underlying network. 200 3. Control Connection establishment 202 3.1. Negotiation phase 204 The multicast extension capability is negotiated between the LAC and 205 the LNS during the control connection establishment phase. However, 206 establishment procedures defined in [RFC2661] remain unchanged. A LAC 207 indicates its multicast extension capability by using a new AVP, the 208 "Multicast Capability" AVP. There is no explicit acknowledgement sent 209 by the LNS during the control connection establishment phase. 210 Instead, the LNS is allowed to use multicast extension messages to 211 open and maintain multicast session(s) (Section 5). 213 3.2. Multicast Capability AVP (SCCRQ, SCCRP) 215 In order to inform the LNS that a LAC has the ability to handle 216 multicast sessions, the LAC sends a Multicast Capability AVP during 217 the control connection establishment phase. 218 This AVP is sent either in a SCCRQ or a SCCRP control message by the 219 LAC towards the LNS. 221 Upon receipt of the Multicast Capability AVP, a LNS may adopt two 222 distinct behaviors: 224 1) The LNS does not implement the L2TP multicast extension: any 225 multicast-related information (including the Multicast Capability 226 AVP) will be silently ignored by the LNS. 227 2) The LNS implements L2TP multicast extensions, and therefore 228 supports the Multicast Capability AVP: the LNS is allowed to send 229 L2TP specific commands for conveying multicast traffic towards the 230 LAC. 232 The multicast capability exclusively refers to the tunnel for which 233 the AVP has been received during control connection establishment 234 phase. It SHOULD be possible for a LNS administrator to shut down 235 L2TP multicast extension features towards one or a set of LAC(s). In 236 this case, the LNS behavior is similar to 1). 238 The AVP has the following format: 240 Vendor ID = 0 241 Attribute = TBA1 (16 bits) (Note: to be assigned by IANA) 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 |M|H|0|0|0|0| Length | Vendor ID | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | TBA1 | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 The M-bit MUST be set to 0, the AVP MAY be hidden (H-bit set to 0 or 252 1). 254 The length of this AVP is 6 octets. 256 4. L2TP multicast session establishment decision 258 4.1. Multicast states in LNS 260 The router that embeds the LNS feature MUST support at least one 261 Group Management Protocol (GMP) such as: 262 - IGMPv1 263 - IGMPv2 264 - MLD 265 or a Source Filtering Group Management Protocol (SFGMP) such as: 266 - IGMPv3 267 - MLDv2 269 The LAC does not have any group management activity: GMP or SFGMP 270 processing is performed by the LNS. The LAC is a layer-2 equipment, 271 and is not supposed to track GMP or SFGMP messages between the 272 receivers and the LNS in this context. 273 The LNS MUST always be at the origin of the creation of a multicast 274 L2TP session dedicated for the forwarding of IP multicast datagrams 275 destined to a multicast group. 276 The LNS acts as a GMP or SFGMP Querier for every logical interface 277 associated to a L2TP session. 279 As a multicast router, the equipment that embeds the LNS function 280 will keep state per group per attached network (i.e. per L2TP 281 session). The LNS-capable equipment activating multicast extensions 282 for L2TP will have to classify and analyze GMP and SFGMP states in 283 order to create L2TP multicast session(s) within the appropriate L2TP 284 tunnel(s). This is performed in three steps: 286 1- The LNS has to compute group states for each L2TP tunnel, using 287 group states recorded for each L2TP session of the tunnel. Group 288 state determination for L2TP tunnels is discussed in section 4.2. For 289 each L2TP tunnel, the result of this computation will issue a list of 290 states of the form (group, filter-mode, source-list): 291 - group: denotes the multicast group 292 - filter-mode: either INCLUDE or EXCLUDE, as defined in 293 [RFC3376] 294 - source-list: list of IP unicast addresses from which multicast 295 reception is desired or not, depending on the filter-mode. 297 2- According to each group state, the LNS will create one or multiple 298 replication contexts, depending on the filter-mode for the considered 299 group and the local policy configured in the LNS. 300 For groups in INCLUDE mode, the LNS SHOULD implement two different 301 policies: 302 - One session per (source, group) pair: the LNS creates one 303 replication context per (source, group) pair. 304 or 305 - One session per group: the LNS creates one replication context 306 per (source-list, group) pair. 308 For groups in EXCLUDE mode, the LNS will create one replication 309 context per (list of sources excluded by *all* the receivers, group). 310 The list of sources represents the intersection of the sets, not the 311 union. 313 3- For each replication context, the LNS will create one L2TP 314 multicast session (if threshold conditions are met, see Section 4.3) 315 and its associated Outgoing Session List (OSL). The OSL lists L2TP 316 sessions that requested the multicast flow corresponding to the group 317 and the associated source-filtering properties. There is one OSL per 318 replication context, i.e. per L2TP multicast session. 320 For a group member running a SFGMP, it is therefore possible to 321 receive multicast traffic from sources that have been explicitly 322 excluded in its SFGMP membership report if other group members in the 323 same L2TP tunnel wish to receive packets from these sources. This 324 behavior is comparable to the case where group members are connected 325 to the same multi-access network. When a group is in EXCLUDE mode or 326 in INCLUDE mode with a policy allowing one session per (group, 327 source-list), sharing the same L2TP tunnel is equivalent to be 328 connected to the same multi-access network in term of multicast 329 traffic received. For groups in INCLUDE mode with a policy allowing 330 one L2TP multicast session per (source, group), the behavior is 331 slightly improved because it prevents group members to receive 332 traffic from non-requested sources. On the other hand, this policy 333 potentially increases the number of L2TP multicast sessions to 334 establish and maintain. Examples are provided in Appendix A. 336 In order for the LAC to forward the multicast traffic received 337 through the L2TP multicast session to group members, the LNS sends 338 the OSL to the LAC for the related multicast session (see Section 6). 340 4.2. Group state determination 342 Source Filtering Group Management Protocols require querier routers 343 to keep a filter-mode per group per attached network, to condense the 344 total desired reception state of a group to a minimum set such that 345 all systems' memberships are satisfied. 347 Within the context of L2TP, each L2TP session has to be considered as 348 an attached network by GMP and SFGMP protocols. When activating L2TP 349 multicast extension, each L2TP Control Connection has to be 350 considered as a pseudo attached network as well in order to condense 351 group membership reports for every L2TP session in the tunnel. 353 Therefore, a list of group states is maintained for each L2TP Control 354 Connection into which the membership information of each of its L2TP 355 sessions is merged. This list of group states is a set of membership 356 records of the form (group, filter-mode, source-list). 357 Each group state represents the result of a merging process applied 358 to subscriptions on L2TP sessions of a Control Connection for a 359 considered group. This merging process is performed in three steps: 360 1- Conversion of any GMP subscription into SFGMP subscription 361 (IGMPv1/v2 to IGMPv3, MLDv1 to MLDv2); 362 2- Removal of subscription timers and, if filter-mode is 363 EXCLUDE, sources with source timer > 0; 364 3- Then, resulting subscription are merged using merging rules 365 described in SFGMP specifications ([RFC3376] Section 3.2, 366 [RFC3810] Section 4.2). 368 This process is also described in [PROXY]. Examples of group state 369 determination are provided in Appendix A. 371 4.3. Triggering 373 The rules to be enforced by the LNS so as to decide when to open a 374 dedicated L2TP multicast session for a multicast group SHOULD be 375 configurable by the LNS administrator. This would typically happen 376 whenever a threshold of MULTICAST_SESSION_THRESHOLD 377 receivers/sessions referenced in a replication context is reached. 378 This threshold value SHOULD be valued at 2 by default, if we consider 379 that it is worth opening a dedicated L2TP multicast session for two 380 group members sharing the same desired reception state (which means 381 that two L2TP unicast sessions are concerned). In this case, the OSL 382 will reference two distinct L2TP sessions. 384 The actual reception by the LNS of multicast traffic requested by 385 end-users can also be taken into account to decide whether the 386 associated L2TP multicast session has to be opened or not. 388 Whenever an OSL gets empty, the LNS MUST stop sending multicast 389 traffic over the corresponding L2TP multicast session. Then the L2TP 390 multicast session MUST be torn down as described in Section 7 of this 391 document. 393 Filter-mode changes for a group can also trigger the opening or the 394 termination of L2TP multicast session(s): 396 a- From INCLUDE mode to EXCLUDE mode 397 When a group state filter-mode switches from INCLUDE to EXCLUDE, only 398 one replication context (and its associated L2TP multicast session) 399 issued from this group state can exist (see Section 4.1). The LNS 400 SHOULD keep one replication context previously created for this group 401 state and has to update it with: 402 -a new source-list that has to be excluded from forwarding 403 -a new OSL 405 The LNS MUST send an OSL update to the LAC to reflect L2TP sessions 406 list changes (section 6.2), whenever appropriate. The unused L2TP 407 multicast sessions that correspond to previously created replication 408 contexts for the group SHOULD be terminated, either actively or 409 passively by emptying their corresponding OSLs. 410 The remaining L2TP multicast session MAY also be terminated if the 411 number of receivers is below a predefined threshold (see Section 7). 412 To limit the duration of temporary packet loss or duplicates to 413 receivers, the LNS has to minimize delay between OSL updates messages 414 sent to the LAC. Therefore, one can assume that terminating a 415 multicast session passively gives the smoothest transition. 417 b- From EXCLUDE mode to INCLUDE mode 419 When a group state filter-mode switches from EXCLUDE to INCLUDE, 420 multiple replication contexts issued by this group state may be 421 created (see Section 4.1). The LNS SHOULD keep the replication 422 context previously created for this group state and has to update it 423 accordingly with the following information: 424 -a new list of sources that has to be forwarded, this list 425 having only one record if there is one replication context per 426 (group, source) 427 -a new OSL 429 The LNS MUST send an OSL update to the LAC to reflect L2TP sessions 430 list changes, whenever appropriate. If the LNS is configured to 431 create one replication context per (group, source), L2TP multicast 432 sessions will be opened in addition to the existing one, depending on 433 the number of sources for the group. 434 If new L2TP multicast sessions need to be opened, the LNS SHOULD wait 435 until these multicast sessions are established before updating the 436 OSL of the original multicast session. To limit the duration of 437 temporary packet loss or duplicates to receivers, the LNS has to 438 minimize delay between OSL updates messages sent to the LAC. 440 4.4. Multicast traffic sent from group members 442 The present document proposes a solution to enhance the forwarding of 443 downstream multicast traffic exclusively, i.e. data coming from the 444 LNS towards end-users connected to the LAC. 445 In the case where a group member that uses a L2TP session is also a 446 multicast source for traffic conveyed in a multicast session, 447 datagrams may be sent back to the source. To prevent this behavior, 448 two options can be used in the LNS: 449 1- Disable the multicast packets forwarding capability, for 450 those multicast datagrams sent by users connected to the 451 network by the means of a L2TP tunnel. Protocols using well- 452 known multicast addresses MUST NOT be impacted. 453 2- Exclude from the OSL the L2TP session used by a group member 454 that sends packets matching the replication context of this 455 OSL. Therefore, the corresponding multicast flow is sent by 456 the LNS over the user L2TP unicast session, using standard 457 multicast forwarding rules. 459 5. L2TP multicast session opening process 461 The opening of an L2TP multicast session is initiated by the LNS. A 462 three-message exchange is utilized to set up the session. Following 463 is a typical sequence of events: 465 LAC LNS 466 --- --- 467 (multicast session 468 triggering) 470 <- MSRQ 471 MSRP -> 473 (Ready to 474 replicate) 476 MSE -> 477 <- ZLB ACK 479 ZLB ACK is sent if there are no further messages waiting in queue for 480 that peer. 482 5.1. Multicast-Session-Request (MSRQ) 484 Multicast-Session-Request (MSRQ) is a control message sent by the LNS 485 to the LAC to indicate that a multicast session can be created. The 486 LNS initiates this message according to the rules mentioned in 487 section 4.2. It is the first in a three-message exchange used for 488 establishing a multicast session within a L2TP tunnel. 490 A LNS MUST NOT send a MSRQ control message if the remote LAC did not 491 open the L2TP tunnel with the Multicast Capability AVP. The LAC MUST 492 ignore MSRQ control messages sent in a L2TP tunnel, if the L2TP 493 tunnel was not opened with control messages including a Multicast 494 Capability AVP. 496 The following AVPs MUST be present in MSRQ: 498 Message Type 499 Assigned Session ID 501 The following AVP MAY be present in MSRQ: 503 Random Vector 504 Maximum BPS 506 The Maximum BPS value is set by the LNS administrator. However, this 507 value should be chosen in accordance with the line capabilities of 508 the end-users. The Maximum BPS value SHOULD NOT be higher than the 509 highest speed connection for all end-users within the L2TP tunnel. 511 The associated Message Type AVP is encoded with the values: 513 Vendor ID = 0 514 Attribute Type = 0 515 Attribute Value = TBA2 (16 bits) (Note: to be assigned by IANA) 517 The M-bit MUST be set to 0, the H-bit MUST be set to 0. 519 5.2. Multicast-Session-Response (MSRP) 521 Multicast-Session-Response (MSRP) is a control message sent by the 522 LAC to the LNS in response to a received MSRQ message. It is the 523 second in a three-message exchange used for establishing a multicast 524 session within a L2TP tunnel. 526 MSRP is used to indicate that the MSRQ was successful and the LAC 527 will attempt to reserve appropriate resources to perform multicast 528 replication for unicast sessions managed in the pertaining control 529 connection. 531 The following AVPs MUST be present in MSRP: 533 Message Type 534 Assigned Session ID 536 The following AVP MAY be present in MSRP: 538 Random Vector 540 The associated Message Type AVP is encoded with the values: 542 Vendor ID = 0 543 Attribute Type = 0 544 Attribute Value = TBA3 (16 bits) (Note: to be assigned by IANA) 546 The M-bit MUST be set to 0, the H-bit MUST be set to 0. 548 5.3. Multicast-Session-Established (MSE) 550 Multicast-Session-Established (MSE) is a control message sent by the 551 LAC to the LNS to indicate that the LAC is ready to receive necessary 552 multicast information (Section 6) for the group using the newly 553 created multicast session. It is the third message in the three- 554 message sequence used for establishing a multicast session within a 555 L2TP tunnel. 557 The following AVP MUST be present in MSE: 559 Message Type 561 The following AVP MAY be present in MSE: 563 Sequencing Required 565 Sequencing will occur only from the LNS to the LAC since a multicast 566 session is only used to forward multicast traffic downstream. 568 The associated Message Type AVP is encoded with the values: 570 Vendor ID = 0 571 Attribute Type = 0 572 Attribute Value = TBA4 (16 bits) (Note: to be assigned by IANA) 574 The M-bit MUST be set to 0, the H-bit MUST be set to 0. 576 6. Session maintenance and management 578 Once the multicast session is established, the LAC has to be informed 579 of the L2TP unicast sessions interested in receiving the traffic from 580 the newly-created multicast session, as well as a related optional 581 priority parameter defined in Section 6.3. To achieve this, a new 582 control message type is defined: Multicast-Session-Information (MSI). 584 6.1. Multicast-Session-Information (MSI) 586 Multicast-Session-Information (MSI) control messages carry AVPs to 587 keep the OSL synchronized between the LNS and the LAC, and to set the 588 optional priority parameter for multicast traffic versus unicast 589 traffic. MSI may be extended to update the multicast session with 590 additional parameters, as needed. 592 Each MSI message is specific to a particular multicast session. 593 Therefore, the control message MUST use the assigned session ID 594 associated to the multicast session (assigned by the LAC), except for 595 the case mentioned in 6.3.2. 597 The associated Message Type AVP is encoded with the values: 599 Vendor ID = 0 600 Attribute Type = 0 601 Attribute Value = TBA5 (16 bits) (Note: to be assigned by IANA) 603 The M-bit MUST be set to 0, the H-bit MUST be set to 0. 605 The following AVPs MUST be present in MSI: 607 Message Type 609 The following AVP MAY be present in MSI: 611 Random Vector 612 New Outgoing Sessions 613 New Outgoing Sessions Acknowledgement 614 Withdraw Outgoing Sessions 615 Multicast Packets Priority 617 New Outgoing Sessions, New Outgoing Sessions Acknowledgement, 618 Withdraw Outgoing Sessions and Multicast Packets Priority are new 619 AVPs defined in sections 6.2 and 6.3. 621 6.2. Outgoing Sessions List updates 623 Whenever a change occurs in the Outgoing Sessions List, the LNS MUST 624 inform the LAC of that change. The OSL is built upon subscription 625 reports recorded by GMP or SFGMP processes running in the LNS 626 (Section 4.1). 627 The LAC maintains an OSL as a local table transmitted by the LNS. As 628 for the LNS, the LAC has to maintain an OSL for each L2TP multicast 629 session within a L2TP tunnel. To update the LAC OSL, the LNS sends a 630 New Outgoing Sessions AVP for additional(s) session(s), or sends a 631 Withdraw Outgoing Sessions AVP to remove session(s). All sessions 632 mentioned in these AVPs MUST be added or removed by the LAC from the 633 relevant OSL. The Outgoing Sessions List is identified by the tunnel 634 ID and the multicast session ID the updating AVP is referring to. 635 To update the OSL, the following AVPs are used: 637 Additional session(s): New Outgoing Sessions AVP 638 Session(s) removal: Withdraw Outgoing Sessions AVP 640 These new AVPs MUST be sent in a MSI message. 642 6.2.1. New Outgoing Sessions AVP (MSI) 644 The New Outgoing Sessions AVP can only be carried within a MSI 645 message type. This AVP piggybacks every Session ID to which the 646 multicast traffic has to be forwarded. 648 The AVP has the following format: 650 Vendor ID = 0 651 Attribute = TBA6 (16 bits) (Note: to be assigned by IANA) 653 0 1 2 3 654 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 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 |M|H|0|0|0|0| Length | Vendor ID | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | TBA6 | Session ID 0 | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | ... | Session ID N | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 There can be from 1 to N Session IDs present in the New Outgoing 664 Sessions AVP (considering the maximum value of the Length field). 665 This AVP must be placed in a MSI message and sent after the 666 establishment of the multicast session to indicate the LAC what are 667 the initial outgoing sessions, and at any time when one or more 668 outgoing sessions appear during the multicast session lifetime. Upon 669 reception of this AVP, the LAC sends a New Outgoing Sessions 670 Acknowledgment AVP to the LNS to notify that the LAC is ready to 671 replicate the multicast traffic towards the indicated sessions. 673 Usage of this AVP is incremental: only new outgoing sessions have to 674 be listed in the AVP. 676 The M-bit MUST be set to 1, the AVP MAY be hidden (H-bit set to 0 or 677 1). 679 6.2.2. New Outgoing Sessions Acknowledgement AVP (MSI) 681 The New Outgoing Sessions Acknowledgement AVP can only be carried 682 within a MSI message type. This AVP informs the LNS that the LAC is 683 ready to replicate traffic for every Session ID listed in the AVP. 685 The AVP has the following format: 687 Vendor ID = 0 688 Attribute = TBA7 (16 bits) (Note: to be assigned by IANA) 690 0 1 2 3 691 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 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 |M|H|0|0|0|0| Length | Vendor ID | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | TBA7 | Session ID 0 | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | ... | Session ID N | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 This AVP must be placed in a MSI message and sent by the LAC towards 701 the LNS to acknowledge the reception of a New Outgoing Sessions list 702 received in a New Outgoing Sessions AVP from the LNS. 704 A LNS is allowed to send multicast traffic within the L2TP multicast 705 session as soon as a New Outgoing Sessions Acknowledgement AVP is 706 received for the corresponding L2TP multicast session. 708 A LNS is allowed to stop sending packets of the corresponding 709 multicast flow within L2TP unicast sessions only if it receives a MSI 710 message with the New Outgoing Session Acknowledgement AVP, and only 711 for the unicast Session IDs mentioned in this AVP. The multicast 712 traffic can then be conveyed in L2TP unicast sessions again when the 713 L2TP multicast session goes down. From this standpoint, packets 714 related to this multicast flow SHOULD NOT be conveyed within the L2TP 715 unicast sessions mentioned in the AVP to avoid the duplication of 716 multicast packets. 718 There can be from 1 to N Session IDs present in the New Outgoing 719 Sessions Acknowledgement AVP (considering the maximum value of the 720 Length field). Session IDs mentioned in this AVP that have not been 721 listed in a previous New Outgoing Sessions AVP should be ignored. 722 Non-acknowledged Session IDs MAY be listed in forthcoming New 723 Outgoing Sessions AVPs, but multicast traffic MUST be sent to logical 724 interfaces associated to these Session IDs as long as these Session 725 IDs are not acknowledged for replication by the LAC. 727 The M-bit MUST be set to 1, the AVP MAY be hidden (H-bit set to 0 or 728 1). 730 6.2.3. Withdraw Outgoing Sessions AVP (MSI) 732 The Withdraw Outgoing Sessions AVP is sent whenever there is one or 733 more withdrawn subscriptions for the corresponding multicast flow 734 (designated by the session ID on which the MSI is sent). 735 The LAC can stop forwarding packets to Session IDs mentioned in the 736 AVP for the corresponding multicast flow as soon as it receives the 737 MSI message embedding this Withdraw Target Session AVP. 739 The AVP has the following format: 741 Vendor ID = 0 742 Attribute = TBA8 (16 bits) (Note: to be assigned by the IANA) 744 0 1 2 3 745 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 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 |M|H|0|0|0|0| Length | Vendor ID | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | TBA8 | Session ID 0 | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | ... | Session ID N | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 There can be from 1 to N Session IDs present in the Withdraw Outgoing 755 Sessions AVP (considering the value of the Length field). The M-bit 756 MUST be set to 1, the AVP MAY be hidden (H-bit set to 0 or 1). 758 6.3. Multicast Packets Priority AVP (MSI) 760 The Multicast Packets Priority AVP is an optional AVP intended to 761 provide the LAC with an indication on how to process multicast 762 traffic against unicast traffic. Even though the LAC behavior is 763 partially described here, the nature of the traffic (layer-2 frames 764 for unicast traffic and pure IP packets for multicast traffic) is not 765 a criteria for enforcing a traffic prioritization policy. Traffic 766 processing for the provisioning of a uniformly-framed traffic for the 767 final user is described is section 8. 769 Three different behaviors can be adopted: 771 1) Best effort: the traffic is forwarded from the LAC to the end-user 772 in the order it comes from the LNS, whatever the type of traffic. 773 2) Unicast traffic priority: traffic coming down the L2TP unicast 774 session has priority over traffic coming down the L2TP multicast 775 session. 776 3) Multicast traffic priority: traffic coming down the L2TP multicast 777 session has priority over traffic coming down the L2TP unicast 778 session. 780 The priority is encoded as a 16-bit quantity, which can take the 781 following values: 783 0: Best effort (default) 784 1: Unicast traffic priority 785 2: Multicast traffic priority 787 The AVP has the following format: 789 Vendor ID = 0 790 Attribute = TBA9 (16 bits) (Note: to be assigned by the IANA) 792 0 1 2 3 793 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 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 |M|H|0|0|0|0| Length | Vendor ID | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | TBA9 | Priority Value | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 It is important to note that the multicast traffic rate can reach up 801 to Maximum BPS (as indicated in MSRQ). This rate can exceed the 802 maximum rate allowed for a particular end-user. This means that even 803 with a priority value of 0, the end-user may receive multicast 804 traffic only: unicast packets might be dropped because the multicast 805 flow overwhelms the LAC forwarding buffer(s). 807 The default Priority Value is 0. The M-bit MUST be set to 0, the AVP 808 MAY be hidden (H-bit set to 0 or 1). 810 There are two ways of using this AVP: global configuration and 811 individual configuration. 813 6.3.1. Global configuration 815 The Multicast Priority Packet AVP is sent for all L2TP unicast 816 sessions concerned with a specific multicast flow represented by a 817 L2TP multicast session. 818 In this case, the AVP is sent in a L2TP MSI control message for the 819 corresponding multicast session ID (Session ID = L2TP session for the 820 corresponding multicast group). The priority value applies to all 821 L2TP unicast sessions to which the multicast group designated by the 822 L2TP multicast session is intended, as soon as this AVP is received. 824 6.3.2. Individual configuration 826 The Multicast Priority Packet AVP is sent for a specific L2TP unicast 827 session that SHALL adopt a specific behavior for both unicast and 828 multicast traffics. In this case, the AVP is sent in a L2TP MSI 829 control message for the L2TP unicast session (Session ID = L2TP 830 session for the concerned user). The priority value applies to the 831 targeted session only, and does not affect the other sessions. It is 832 important to note that in this case, all multicast packets carried in 833 L2TP multicast sessions are treated the same way by the LAC for the 834 concerned user. 835 This is the only case where a MSI control message can be sent for a 836 L2TP unicast session. 838 6.3.3. Priority 840 It is the responsibility of the network administrator to decide which 841 behavior to adopt between global or individual configurations, if the 842 AVP is sent twice (one for a multicast group and one for a specific 843 end-user). By default, only the individual configurations SHOULD be 844 taken into consideration in that case. 846 Support of the Multicast Packets Priority AVP is optional and SHOULD 847 be configurable by the LAC administrator, if relevant. 849 7. Multicast session teardown 851 A L2TP multicast session should be torn down whenever there are no 852 longer users interested in receiving the corresponding multicast 853 traffic. More specifically, we consider that a multicast session 854 becomes useless as soon as the related OSL has less than a predefined 855 number of entries, this number being defined by a threshold. 856 Multicast session flapping may occur when the number of OSL entries 857 is oscillating around the threshold, if the same value is used to 858 trigger the creation or the deletion of a L2TP multicast session. 859 To avoid this behavior, two methods can be used: 861 - The threshold value used to determine if the L2TP multicast 862 session has to be torn down is lower than the 863 MULTICAST_SESSION_THRESHOLD value; 864 - The MULTICAST_SESSION_THRESHOLD value is used to determine if 865 the L2TP multicast session has to be torn down. A multicast session 866 SHOULD be killed after a period of MULTICAST_SESSION_HOLDTIME seconds 867 if the corresponding OSL maintains less than 868 MULTICAST_SESSION_THRESHOLD entries. The MULTICAST_SESSION_HOLDTIME 869 value is 10 seconds by default, and SHOULD be configurable either by 870 the LAC or the LNS administrator. 872 The multicast session can be torn down for multiple reasons, 873 including specific criteria not described here (can be vendor- 874 specific). 875 A multicast session teardown can be initiated either by the LAC or 876 the LNS. However, multicast session teardown MUST be initiated by the 877 LNS if the termination decision is motivated by the number of users 878 interested in receiving the traffic corresponding to a multicast 879 flow. 881 7.1. Operations 883 The actual termination of a multicast session is initiated with a new 884 Multicast-Session-End-Notify (MSEN) control message, sent either by 885 the LAC or by the LNS. 887 The following is an example of a control messages exchange that 888 terminates a multicast session: 890 LAC or LNS LAC or LNS 891 ---------- ---------- 892 (multicast session 893 termination) 895 <- MSEN 896 (Clean up) 897 ZLB ACK -> 898 (Clean up) 900 7.2. Multicast-Session-End-Notify (MSEN) 902 The Multicast-Session-End-Notify (MSEN) is a L2TP control message 903 sent by either the LAC or the LNS to request the termination of a 904 specific multicast session within the tunnel. Its purpose is to 905 inform the peer with the relevant termination information, including 906 the reason why the termination occurred. The peer MUST clean up any 907 associated resources, and does not acknowledge the MSEN message. 909 As defined in [RFC2661], termination of a control connection will 910 terminate all sessions managed within, including multicast sessions 911 if any. 913 The MSEN message carries a Result Code AVP with an optional Error 914 Code. 916 The following AVPs MUST be present in a MSEN message: 918 Message Type 919 Result Code 920 Assigned Session ID 922 The associated Message Type AVP is encoded with the following values: 924 Vendor ID = 0 925 Attribute Type = 0 926 Attribute Value = TBA10 (16 bits) (Note: to be assigned by IANA) 928 The M-bit MUST be set to 0, the H-bit MUST be set to 0. 930 7.3. Result Codes 932 The following values are the defined result codes for MSEN control 933 messages: 935 TBA11 (16 bits) - Session terminated for the reason indicated in 936 the error code 937 TBA12 (16 bits) - No multicast traffic to forward 938 TBA13 (16 bits) - No more receivers 939 TBA14 (16 bits) - No more receivers (filter-mode change) 941 (Note: TBA11, TBA12, TBA13 and TBA14 to be defined by the IANA) 943 o The code TBA11 refers to General Error Codes maintained by the 944 IANA for L2TP. 945 o The code TBA12 MAY be used when the LAC detects that no traffic 946 is coming down the multicast session, or when the LNS doesn't receive 947 multicast traffic to be conveyed over the L2TP multicast session 948 during a certain period of time. 949 o The code TBA13 MAY be used by the LAC or the LNS when the OSL is 950 empty. 951 o The code TBA14 MAY be used by the LNS when a multicast session 952 is torn down because of a filter-mode change. This result code SHOULD 953 also be used when the OSL becomes empty after a filter-mode change 954 (passive termination when filter-mode change from INCLUDE to EXCLUDE, 955 Section 4.3). 957 8. Traffic merging 959 Both unicast and multicast traffics have to be merged by the LAC in 960 order to forward properly framed data to the end-user. Multicast 961 packets are framed by the LAC and transmitted towards the proper end- 962 user. Methods to achieve this function are not described here, since 963 it is an implementation-specific issue. 964 All frames conveyed from the LAC to the end-users have to follow the 965 framing scheme applied for the considered peer to which the traffic 966 is destined (e.g. the LAC is always aware of the PPP link parameters, 967 as described in [RFC2661], Section 6.14). It has to be noted that 968 using L2TP Multicast Extension features is not appropriate for end- 969 users who have negotiated a sequenced layer-2 connection with the 970 LNS: while inserting PPP-encapsulated multicast packets in a session, 971 the LAC cannot modify PPP sequencing performed by the LNS for each 972 PPP session. 974 9. IANA Considerations 976 This document defines: 977 - 5 new Message Type (Attribute Type 0) Values: 978 o Multicast-Session-Request (MSRQ) : TBA2 979 o Multicast-Session-Response (MSRP) : TBA3 980 o Multicast-Session-Establishment (MSE) : TBA4 981 o Multicast-Session-Information (MSI) : TBA5 982 o Multicast-Session-End-Notify (MSEN) : TBA10 983 - 5 new Control Message Attribute Value Pairs: 984 o Multicast Capability : TBA1 985 o New Outgoing Sessions : TBA6 986 o New Outgoing Sessions Acknowledgement : TBA7 987 o Withdraw Outgoing Sessions : TBA8 988 o Multicast Packets Priority : TBA9 989 - 4 Result Codes for the MSEN message: 990 o Session terminated for the reason indicated in the 991 error code : TBA11 992 o No multicast traffic for the group : TBA12 993 o No more receivers : TBA13 994 o No more receivers (filter-mode change): TBA14 996 IANA will assign, register and maintain values for these new 997 attributes ([RFC3438]). 999 10. Security Considerations 1001 It is possible for one receiver to be able to make additional 1002 multicast traffic that has not been requested go down the link of 1003 another receiver. This can happen if a single replication context per 1004 group is used in INCLUDE mode with receivers having divergent source 1005 lists, as well as in EXCLUDE mode if a receiver has a source list not 1006 shared by another. This behavior can be encountered every time 1007 receivers are connected to a common multi-access network. 1009 The extension described in this document does not introduce any 1010 additional security issues as far as the activation of the L2TP 1011 protocol is concerned. 1013 Injecting appropriate control packets in the tunnel towards a LAC to 1014 modify Outgoing Session List and flood end-users with unwanted 1015 multicast traffic is only possible if the control connection is 1016 hacked. As for any reception of illegitimate L2TP control messages: 1018 - If the spoofed control message embeds consistent sequence 1019 numbers, next messages will appear out of synch yielding the control 1020 connection to terminate. 1021 - If sequence numbers are inconsistent with current control 1022 connection states, the spoofed control message will be queued or 1023 discarded, as described in [RFC2661] section 5.8. 1025 The activation of the L2TP multicast capability on a LAC could make 1026 the equipment more sensitive to Denial of Service attacks if the 1027 control connection or the related LNS is hacked. The LAC might also 1028 be sensitive to the burden generated by the additional replication 1029 work. 1031 As mentioned in [RFC2661] section 9.2, securing L2TP requires that 1032 the underlying transport makes encryption, integrity and 1033 authentication services available for all L2TP traffic, including 1034 L2TP multicast traffic (control and data). 1036 11. References 1038 11.1. Normative References 1040 [RFC1112] S. Deering, "Host Extensions for IP Multicasting", 1041 RFC 1112, August 1989. 1043 [RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", STD 1044 51, RFC 1661, July 1994. 1046 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1047 Requirement Levels", BCP 14, RFC 2119, March 1997. 1049 [RFC2236] W. Fenner, "Internet Group Management Protocol, Version 1050 2", RFC 2236, November 1997. 1052 [RFC2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, 1053 B. Palter, "Layer 2 Tunneling Protocol "L2TP" ", 1054 RFC2661, August 1999. 1056 [RFC2710] S. Deering, W. Fenner, B. Haberman, "Multicast Listener 1057 Discovery (MLD) for IPv6", RFC 2710, October 1999. 1059 [RFC3376] B. Cain et. al., "Internet Group Management Protocol, 1060 Version 3", RFC 3376, October 2002. 1062 [RFC3438] W. Townsley, "Layer Two Tunneling Protocol (L2TP) 1063 Internet Assigned Numbers Authority (IANA) 1064 Considerations Update", RFC 3438, December 2002. 1066 [RFC3810] Vida, R., L. Costa, S.Fdida, S. Deering, B. Fenner, I. 1067 Kouvelas, and B. Haberman, "Multicast Listener Discovery 1068 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1070 11.2. Informative References 1072 [PROXY] Fenner, B., He, H., Haberman, B., Sandick, H., 1073 "IGMP/MLD-based Multicast Forwarding ("IGMP/MLD 1074 Proxying")", Work in Progress. 1076 12. Acknowledgments 1078 Thanks to Christian Jacquenet for all the corrections done on this 1079 document and his precious advice, Pierre Levis for his contribution 1080 about IGMP, Francis Houllier for PPP considerations and Xavier Vinet 1081 for his input about thresholds. Many thanks to W. Mark Townsley, 1082 Isidor Kouvelas and Brian Haberman for their highly valuable input on 1083 protocol definition. 1085 13. Author's Addresses 1087 Gilles Bourdon 1088 France Telecom 1089 38-40, rue du General Leclerc 1090 92794 Issy les Moulineaux Cedex 9 - FRANCE 1091 Phone: +33 1 4529-4645 1092 Email: gilles.bourdon@francetelecom.com 1094 Appendix A. Examples of group states determination 1096 *Example 1: 1098 All users are managed in the same control connection. 1100 Users {1, 2, 3} subscribe to (Group G1, EXCLUDE {}) 1101 Users {3, 4, 5} subscribe to (Group G2, EXCLUDE {}) 1103 Group states for this L2TP tunnel will be: 1104 (G1, EXCLUDE, {}) 1105 (G2, EXCLUDE, {}) 1107 Therefore, two replication contexts will be created: 1108 -RC1: 1109 (*, G1) packets, Multicast Session MS1, OSL = 1, 2, 3 1110 -RC2: 1111 (*, G2) packets, Multicast Session MS2, OSL = 3, 4, 5 1113 *Example 2: 1115 All users are managed in the same control connection. 1117 Users {1, 2, 3} subscribe to (Group G1, INCLUDE {S1}) 1118 Users {4, 5, 6} subscribe to (Group G1, INCLUDE {S1,S2}) 1119 Users {7, 8, 9} subscribe to (Group G1, INCLUDE {S2}) 1121 The group state for this L2TP tunnel will be: 1122 (G1, INCLUDE, {S1, S2)}) 1124 If the LNS policy allows one replication context per (group, source), 1125 two replication contexts will be created: 1126 -RC1: 1127 (S1, G1) packets, Multicast Session MS1, OSL = 1, 2, 3, 4, 5, 6 1128 -RC2: 1129 (S2, G1) packets, Multicast Session MS2, OSL = 4, 5, 6, 7, 8, 9 1131 If the LNS policy allows one replication context per (group, source- 1132 list), one replication context will be created: 1133 -RC1: 1134 ({S1, S2}, G1) packets, Multicast Session MS1, OSL = [1..9] 1136 *Example 3: 1138 All users are managed in the same control connection. 1140 Users {1, 2} subscribe to (Group G1, EXCLUDE {S1}) 1141 User {3} subscribes to (Group G1, EXCLUDE {S1, S2}) 1143 The group state for this L2TP tunnel will be: 1144 (G1, EXCLUDE, {S1}) 1146 Therefore, one replication context will be created: 1147 -RC1: 1148 (*-{S1}, G1) packets, Multicast Session MS1, OSL = 1, 2, 3 1150 Next, user {4} subscribes to (Group G1, INCLUDE {S1}). The group 1151 state for the L2TP tunnel is changed to: 1152 (G1, EXCLUDE, {}) 1154 The replication context RC1 is changed to: 1155 -RC1: (*, G1) packets, Multicast Session MS1, OSL = 1, 2, 3, 4 1157 *Example 4: 1159 All users are managed in the same control connection. The LNS policy 1160 allows one replication context per (group, source). 1162 Users {1, 2, 3} subscribe to (Group G1, INCLUDE {S1, S2}) 1164 The group state for this L2TP tunnel will be: 1165 (G1, INCLUDE, {S1, S2)}) 1167 Therefore, two replication contexts will be created: 1168 -RC1: 1169 (S1, G1) packets, Multicast Session MS1, OSL = 1, 2, 3 1170 -RC2: 1171 (S2, G1) packets, Multicast Session MS2, OSL = 1, 2, 3 1173 Next, user {4} subscribes to (Group G1, EXCLUDE {}), equivalent to an 1174 IGMPv2 membership report. The group state for the L2TP tunnel is 1175 changed to: 1176 (G1, EXCLUDE, {}) 1178 The replication context RC1 is changed to: 1179 -RC1: (*, G1) packets, Multicast Session MS1, OSL = 1, 2, 3, 4 1181 The replication context RC2 is changed to: 1182 -RC2: no packets to forward, Multicast Session MS2, OSL = {} 1183 (Multicast Session MS2 will be deleted) 1185 When user {4} leaves G1, the group state for the L2TP tunnel goes 1186 back to: 1187 (G1, INCLUDE, {S1, S2}) 1189 Replication contexts become: 1190 -RC1: 1191 (S1, G1) packets, Multicast Session MS1, OSL = 1, 2, 3 1192 -RC2: 1194 (S2, G1) packets, Multicast Session MS2, OSL = 1, 2, 3 1195 (Multicast Session MS2 is re-established) 1197 Full Copyright Statement 1199 Copyright (C) The Internet Society (2004). This document is subject 1200 to the rights, licenses and restrictions contained in BCP 78, and 1201 except as set forth therein, the authors retain all their rights. 1203 This document and translations of it may be copied and furnished to 1204 others, and derivative works that comment on or otherwise explain it 1205 or assist its implementation may be prepared, copied, published and 1206 distributed, in whole or in part, without restriction of any kind, 1207 provided that the above copyright notice and this paragraph are 1208 included on all such copies and derivative works. However, this 1209 document itself may not be modified in any way, such as by removing 1210 the copyright notice or references to the Internet Society or other 1211 Internet organizations, except as needed for the purpose of 1212 developing Internet standards in which case the procedures for 1213 copyrights defined in the Internet Standards process must be 1214 followed, or as required to translate it into languages other than 1215 English. 1217 The limited permissions granted above are perpetual and will not be 1218 revoked by the Internet Society or its successors or assigns. 1220 This document and the information contained herein are provided on an 1221 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1222 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1223 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1224 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1225 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1226 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.