idnits 2.17.1 draft-zheng-pim-multicast-pm-config-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5384]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2010) is 5034 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) == Unused Reference: 'RFC4601' is defined on line 417, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group L. Zheng 2 Internet Draft H. Liu 3 Intended status: Standards Track Huawei Technologies 4 Expires: January 2011 July 5, 2010 6 PIM Multicast Performance Monitoring Configuration (M-PMC) Join 7 Attribute 9 draft-zheng-pim-multicast-pm-config-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 5, 2010. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 Abstract 51 This draft introduces a new type of PIM Join Attribute which carries 52 measurement configuration TLVs, which are used for multicast 53 performance monitoring. It is based on [RFC5384], and specifies 54 additional procedures to process the Multicast Performance 55 Monitoring Configuration (M-PMC) attribute to implement automatic 56 performance monitoring configuration on multicast forwarding tree. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC-2119 [RFC2119]. 64 Table of Contents 66 1. Introduction.................................................2 67 2. Use of M-PMC Join Attribute..................................3 68 2.1. Overview................................................3 69 2.2. Sending M-PMC Join Attribute............................4 70 2.3. Receiving M-PMC Join Attribute..........................5 71 2.4. Conflict Resolution.....................................6 72 2.5. Configuration Failure...................................7 73 3. Packet Format................................................7 74 3.1. PIM M-PMC Join Attribute Format.........................7 75 3.2. Configuration TLV Format................................8 76 3.3. PIM M-PMC Hello Option..................................9 77 4. Security Considerations.....................................10 78 5. IANA Considerations.........................................10 79 6. Acknowledgments.............................................10 80 7. References..................................................10 81 7.1. Normative References...................................10 82 Authors' Addresses.............................................11 84 1. Introduction 86 Service Providers have been leveraging IP multicast to provide 87 revenue-generating services, such as IP television (IPTV), video 88 conferencing, as well as the distribution of stock quotes or news. 89 These services are usually loss-sensitive or delay-sensitive, and 90 their data packets need to be delivered over a large scale IP 91 network in real-time. Providing monitoring support for multicast is 92 important for building robust multicast services. 94 This draft introduces a new type of PIM Join Attribute which carries 95 measurement configuration TLVs, which are used for multicast 96 performance monitoring. It is based on [RFC5384], and specifies 97 additional procedures to process the Multicast Performance 98 Monitoring Configuration (M-PMC) attribute to implement automatic 99 performance monitoring configuration on multicast forwarding tree. 101 2. Use of M-PMC Join Attribute 103 2.1. Overview 105 This draft introduces a Multicast Performance Monitoring 106 Configuration (M-PMC) Join Attribute used for multicast performance 107 monitoring configuration. When network management personnel want to 108 initiate a measurement session for a certain multicast group on a 109 certain multicast forwarding path, e.g. a packet loss measurement, 110 he could initiate the configuration on the leaf router through 111 Command Line Interface or network management protocol and other 112 control protocol. Configuration TLVs for different measurement 113 entities will be included in the M-PMC attribute by the leaf router, 114 and sent hop-by-hop towards the upstream router and the root (either 115 the source or RP router) along the multicast tree. When upstream 116 router receives the Join message, it will examine the attribute and 117 determine which Configuration TLV to apply. It may also either pass 118 the attribute upwards as is or remove some of the TLVs from the 119 attribute, or even remove the whole attribute from the Join message 120 and not passing further upwards. Section 2.2 to 2.5 specifies the 121 procedures to process the M-PMC attribute when sending and receiving 122 Join message, and to resolve the configuration conflict and failure. 124 Figure 1 illustrates a small multicast tree to be monitored; three 125 functional entities are defined for performance monitoring [Y.1731]: 126 MEP_I (Maintenance Entity Group End Point Ingress), MIP (Maintenance 127 Entity Group Intermediate Point) and MEP-E (Maintenance Entity Group 128 End Point Egress). They are logical entities that can be configured 129 on the upstream or downstream interfaces of the monitoring 130 equipments. In this example, downstream interface of the root node 131 is configured as MEP_I, upstream and downstream interfaces of 132 intermediate nodes are configured as MIPs, and upstream interfaces 133 of leaf nodes are configured as MEP_Es. 135 I +--------+ 136 +---<> Leaf 2 | 137 +----------+ G | +--------+ 138 +----------+ C E | <>----+ 139 +------+ A B | <>-----<> Router 2 | 140 | Root <>------<> Router 1 | | <>----+ 141 +------+ | <>---+ +----------+ H | J +--------+ 142 . +----------+ D | +---<> Leaf 3 | 143 . . . | F +--------+ +--------+ 144 . . . +--<> Leaf 1 | . 145 . . . +--------+ . 146 . . . . . . 147 MEP_I MIP1 MIP2 MIP5 MIP6 MEP_E2 148 MIP3 MEP_E1 MIP7 MEP_E3 150 <> Interface 151 ------ Link 153 Figure 1. An example of multicast forwarding tree to be monitored 155 Three types of configuration TLVs are defined for different 156 functional entities; they are MEP_E Configuration TLV, MEP_I 157 Configuration TLV and MIP Configuration TLV for MEP_E, MEP_I and MIP 158 entity configuration respectively. Network management personnel 159 could make their own decision to include which TLV in the attribute, 160 depending on the monitoring requirement. 162 In each Configuration TLV, different measurement function 163 information could be carried. Network management personnel could e.g. 164 either enable a packet delay measurement function on the upstream 165 interface of an intermediate node, or set up the OAM packet sending 166 period at the MEP_E. See section 3.1 and 3.2 for the format of M-PMC 167 Join Attribute and different type of Configuration TLVs. 169 2.2. Sending M-PMC Join Attribute 171 If the leaf router is initiated for configuration, it will include 172 the M-PMC Join Attribute when sending a PIM Join message. 173 Configuration TLVs for different measurement entities will be 174 included in the attribute, and sent hop-by-hop towards the upstream 175 router and the root (either the source or RP router) along the 176 multicast tree. Not all types of TLV need to present in the 177 attribute, but at least MEP_I Configuration TLV will present. See 178 section 3.1 and 3.2 for the format definitions of M-PMC Join 179 Attribute and different type of Configuration TLVs. 181 If the leaf router itself is configured as MEP_E, then the MEP_E 182 Configuration TLV MUST NOT be included in the attribute. The MEP_E 183 Configuration TLV MUST be included in the attribute when a non-leaf 184 node on the multicast path is assigned as MEP_E. In this case the 185 interface address of that node will be included in the MEP_E 186 Configuration TLV. 188 2.3. Receiving M-PMC Join Attribute 190 When processing a received PIM Join that contains an M-PMC Attribute, 191 a router MUST first check to see if the MEP_E Configuration TLV is 192 present. If so, it MUST then check to see if the Configuration 193 Interface Address in the TLV is one of its own IP addresses. If so, 194 it will apply the configurations described in this TLV to its 195 upstream and/or downstream interfaces. The MEP_E TLV is then removed 196 from the attribute, and not passed further upstream. If the 197 Configuration Interface Address is not any of its own IP address, 198 none of the TLVs will be applied and the attribute will be kept the 199 same and passed along when a PIM Join is sent upstream. 201 If no MEP_E Configuration TLV is present, a router MUST then check 202 to see if the Configuration Interface Address in the MEP_I 203 Configuration TLV is one of its own IP addresses. If so, the MEP_I 204 Configuration TLV will be applied and the whole attribute is then 205 removed from the Join message, not passed further upstream. If the 206 Configuration Interface Address is not any of its own IP address, 207 the MIP TLV will be applied when it is present. Otherwise, no TLV 208 will be applied and the attribute will be kept the same and passed 209 along when a PIM Join is sent upstream. 211 +-----------------------------+-----------------+------------------+ 212 | MEP_E TLV | MEP_I TLV | MIP TLV | 213 +-------+------+--------------+------+----------+-------+----------+ 214 |Present|If Add| Action |If Add| Action |Present| Action | 215 +-------+------+--------------+------+----------+-------+----------+ 216 | Yes | Yes | Apply/Remove | - | Not Apply| - | Not Apply| 217 +-------+------+--------------+------+----------+-------+----------+ 218 | Yes | No |Not Apply/Keep| - | Not Apply| - | Not Apply| 219 +-------+------+--------------+------+----------+-------+----------+ 220 | No | - | - | Yes | Apply | - | Not Apply| 221 +-------+------+--------------+------+----------+-------+----------+ 222 | No | - | - | No | Not Apply| Yes | Apply | 223 +-------+------+--------------+------+----------+-------+----------+ 225 Figure 2: Configuration action when receiving M-PMC Join Attribute 226 in tabular form 228 2.4. Conflict Resolution 230 On an upstream router, a conflict occurs when it has received 231 different PIM M-PMC attributes from Join packets sent by its 232 downstream routers. 234 As an example, considering Figure 1 and suppose a M-PMC Join 235 Attribute is used to configure the packet loss measurement function. 236 There are 2 receivers for the same group connected to Leaf2 and 237 Leaf3 respectively. Suppose Leaf2 wants to enable all the nodes on 238 its forwarding path this function and Leaf3 wants to disable all the 239 nodes on its forwarding path the same function. If both Leaf2 and 240 Leaf3 send a Join including an attribute indicating their 241 configuration to their upstream router Router2, Router2 will get 242 conflicting attribute. If this happens, Router2 SHOULD try to merge 243 the different attributes. The upstream interface E and downstream 244 interface G should be enabled for packet loss measurement function, 245 and another downstream interface H should be disabled for this 246 function. An emerged attribute of enabling the function will be and 247 included passed along when a PIM Join is sent upstream. 249 In any case if a branching point router fails to merge the 250 conflicting attributes, no more attribute should be passed further 251 upstream and the configuration is halted. An alert should be sent to 252 the NMS immediately. This could be done by a mechanism provided by 253 NMS and is out of scope of this draft. 255 2.5. Configuration Failure 257 In any case if a node on the multicast forwarding path fails to 258 perform the configuration indicating by the M-PMC attribute, no more 259 attribute should be passed further upstream and the configuration is 260 halted. 262 An alert should be sent to the NMS immediately. It could be done by 263 a mechanism provided by NMS and is out of scope of this draft. 265 3. Packet Format 267 3.1. PIM M-PMC Join Attribute Format 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 |F|E| Attr_Type | Length | Version | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | MEP_E Configuration TLV | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | MEP_I Configuration TLV | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | MIP Configuration TLV | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 - F bit: As specified by [RFC5384] 283 - S bit: As specified by [RFC5384] 285 - Attr_Type: 4 287 - Length: As specified by [RFC5384] 289 - Version: The version of the attribute, current value is 0 291 - MEP_E Configuration TLV: TLV used for MEP_E configuration 293 - MEP_I Configuration TLV: TLV used for MEP_I configuration 295 - MIP Configuration TLV: TLV used for MIP configuration 297 3.2. Configuration TLV Format 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Type | Length | Flags | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Configuration Interface Address | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 |Fun 1 Con Type | Fun 1 Con If | Fun 1 Optional Length | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 ~ Fun 1 Optional Value ~ 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 |Fun 2 Con Type | Fun 2 Con If | Fun 2 Optional Length | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 ~ Fun 2 Optional Value ~ 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 - Type: 1-octet, specifying the configuration TLV type. 317 - 1: MEP_E Configuration TLV 319 - 2: MEP_I Configuration TLV 321 - 3: MIP Configuration TLV 323 - Length: 1-octet, specifying the length in octets of the value 324 field. 326 Configuration values for different measurement function could be 327 included in the same TLV. Fun Con Type field and Fun Con If field, 328 denoted as (Fun Con Type, Fun Con If), are used together to indicate 329 enabling or disabling corresponding function on upstream or/and 330 downstream interfaces of the node. Flags are used to indicate the 331 measurement functions to be configured. When set, there will be 332 corresponding (Fun Con Type, Fun Con If) included in the TLV. 334 - Flags: 2-octets, including 16 1-bit flags, each is defined 335 indicating the measurement functions to be configured 337 - 1rst bit: Packet Loss measurement indication. When set, there is 338 (Fun Con Type, Fun Con If) for packet Loss measurement is included 339 in the TLV. When cleared, there is no (Fun Con Type, Fun Con If) 340 for packet Loss measurement 341 - 2nd bit: Packet Delay measurement indication 343 - 3rd bit to 16th bit: Reserved for indication for other 344 measurement functions which are not defined here at this moment 346 - Configuration Interface Address: 4-octets, specifying the 347 interface address of the node which is assigned as MEP_E when 348 included in MEP_E Configuration TLV. Specifying the interface 349 address of the node which is assigned as MEP_I when included in 350 MEP_I Configuration TLV. SHOULD NOT present in MIP Configuration 351 TLV 353 - Fun Con Type: 1-octet, function configuration type. 355 - 1: Enable 357 - 2: Disable 359 - Fun Con If: 1-octet, function configuration interface, specifying 360 which interface to apply the configuration. 362 - 1: Upstream interface 364 - 2: Downstream interface 366 - 3: Both upstream interface and downstream interface 368 - Fun Optional Length: 2-octets, specifying the length in octets of 369 the additional configuration value field. Set to zero when no 370 additional configuration value is included. 372 - Fun Optional Value: Optional, indicating additional configuration 373 value for corresponding function, e.g. the OAM packet sending 374 period at the MEP_I. Semantics is not defined at this moment. 376 3.3. PIM M-PMC Hello Option 378 A router MUST include PIM M-PMC Hello Option in its PIM Hello 379 packets if it supports this draft. The format of the Option TLV is 380 defined to be: 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | OptionType | OptionLength | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 - OptionType:39 390 - OptionLength:0 392 4. Security Considerations 394 As a new type of PIM Join Attribute, the security considerations 395 described in [RFC5384] apply here. 397 5. IANA Considerations 399 A new PIM Hello Option type needs to be assigned. 39 is proposed for 400 now. 402 A new PIM Join Attribute type needs to be assigned. 4 is proposed 403 for now. 405 6. Acknowledgments 407 Special thanks should be given to the ones who provide valuable 408 comments on the work. 410 7. References 412 7.1. Normative References 414 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 415 Requirement Levels", RFC 2119, March 1997. 417 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 418 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 419 Specification (Revised)", RFC 4601, August 2006. 421 [RFC5384] A. Boers, I. Wijnands, E. Rosen, "The Protocol Independent 422 Multicast (PIM) Join Attribute Format", RFC 5384, November 2008. 424 [Y.1731]ITU-T Recommendation Y.1731 (02/2008), " OAM functions and 425 mechanisms for Ethernet based networks ", Feb,2008. 427 Authors' Addresses 429 Lianshu Zheng 430 Huawei Technologies Co., Ltd. 431 Huawei Building, No.3 Xinxi Road, 432 Hai-Dian District, 433 Beijing 100085 434 China 436 Email: verozheng@huawei.com 438 Liu Hui 439 Huawei Technologies Co., Ltd. 440 Huawei Building, No.3 Xinxi Road, 441 Hai-Dian District, 442 Beijing 100085 443 China 445 Email: liuhui47967@huawei.com