idnits 2.17.1 draft-liu-mboned-multicast-realstream-monitor-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2010) is 5037 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: '1' is defined on line 631, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-02) exists of draft-bipi-mboned-ip-multicast-pm-requirement-01 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group H. Liu 2 Internet Draft M. Chen 3 Intended status: Proposed Standard L. Zheng 4 Huawei Technologies 5 Expires: January 12, 2011 July 12, 2010 7 IP Multicast Inline Real Stream Monitoring 9 draft-liu-mboned-multicast-realstream-monitor-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may not be modified, 18 and derivative works of it may not be created, and it may not be 19 published except as an Internet-Draft. 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. This document may not be modified, 23 and derivative works of it may not be created, except to publish it 24 as an RFC and to translate it into languages other than English. 26 This document may contain material from IETF Documents or IETF 27 Contributions published or made publicly available before November 10, 28 2008. The person(s) controlling the copyright in some of this 29 material may not have granted the IETF Trust the right to allow 30 modifications of such material outside the IETF Standards Process. 31 Without obtaining an adequate license from the person(s) controlling 32 the copyright in such materials, this document may not be modified 33 outside the IETF Standards Process, and derivative works of it may 34 not be created outside the IETF Standards Process, except to format 35 it for publication as an RFC or to translate it into languages other 36 than English. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet-Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 This Internet-Draft will expire on January 12, 2011.. 54 Copyright Notice 56 Copyright (c) 2010 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with 64 respect to this document. 66 Abstract 68 This document defines an efficient IP multicast performance 69 monitoring method through packet loss and packet delay measurement. 70 It has the characteristics of monitoring real IP multicast stream 71 with the measurement packets following the actual multicast 72 forwarding path and it enables the fault detection and isolation in 73 IP multicast network. 75 Table of Contents 77 1. Introduction.................................................3 78 2. Conventions used in this document............................3 79 2.1. Terminologies...........................................3 80 3. Characteristics of IRSM......................................4 81 4. IRSM Message.................................................5 82 4.1. Encapsulation...........................................5 83 4.2. Loss Measurement Message................................6 84 4.3. Delay Measurement Message...............................7 85 5. Principle of IRSM............................................8 86 5.1. Measurement Architecture................................8 87 5.2. Packet Loss Measurement.................................9 88 5.3. Packet Delay Measurement...............................10 89 6. Application in multicast network monitoring.................11 90 6.1. Fault Detection and Localization Based on LM...........11 91 6.2. Fault Detection and Localization Based on DM...........12 92 7. Deployment Considerations...................................12 93 7.1. Acquisition of monitored stream........................12 94 7.2. Alarm and Reporting Processing.........................12 95 7.3. Configuration of Monitoring Nodes......................12 96 7.4. Topology Discovery.....................................12 97 7.5. Interoperation among Different Vendors.................12 98 8. Security Considerations.....................................12 99 9. IANA Considerations.........................................12 100 10. References.................................................12 101 10.1. Normative References..................................12 102 10.2. Informative References................................12 103 11. Acknowledgments............................................12 105 1. Introduction 107 With the deployment of IP video multicast service, there is an 108 increasing demand for the performance monitoring for providers' 109 multicast network. The benefits of performance monitoring are to 110 guarantee the service level agreement (SLA) provided to the customers, 111 to discover the network performance defects proactively, to react in 112 response to the failure quickly, and further to optimize the network 113 resources utilizations. 115 This document describes an IP multicast network performance 116 monitoring solution referred to as Inline Real Stream Monitoring 117 (IRSM) based on the requirements given in [3]. IRSM is proposed to 118 meet the service provider's manageability requirements on 119 increasingly deployed multicast network. It enables efficient 120 measurement of performance metrics of a multicast channel and 121 provides diagnostic information in case of performance degradation or 122 failure. 124 2. Conventions used in this document 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC-2119. 130 2.1. Terminologies 132 IRSM: Inline Real Stream Monitoring 134 (S,G): a source address and group address pair to identify a 135 multicast forwarding channel or multicast forwarding state. 137 (*,G): a notation for multicast forwarding state to receive from all 138 the sources sending to this group. 140 MEG: Maintenance Entity Group 142 MEP: MEG Maintenance Point 144 MEP_I: MEP Ingress 146 MEP_E: MEP Egress 148 MIP: MEG Intermediate Point 150 On-demand: OAM operation manner initiated manually and for a limited 151 amount of time, usually for fault diagnostics. 153 Proactively: preconfigured OAM operation manner either running 154 periodically and continuously, or acting on certain events such as 155 alarm signals. 157 3. Characteristics of IRSM 159 IRSM currently utilizes packet Loss Measurement (LM) and packet Delay 160 Measurement (DM) to accomplish performance monitoring. It has 161 following features desirable as a carrier-grade monitoring scheme, as 162 required in [3]: 164 o Independency - It is operated independently from multicast 165 forwarding plane and control plane and it does not have bad 166 influences on the running of the two planes. 168 o Real stream - The data to be monitored is from real multicast 169 stream, usually specified by (*,G) or (S,G) pairs. 171 o Inline - It enables the on-the-spot measurement or monitoring when 172 carrier network is loaded with customer multicast traffic. 174 o Inband - The OAM measurement packet is routed following strictly 175 the same multicast forwarding path as the monitored multicast stream, 176 which help gathering the true network forwarding metrics. 178 o End-to-End and per segment measurement - It is capable of 179 monitoring the whole end-to-end forwarding path from one multicast 180 root to one or more leaf nodes, which provides the path performance 181 for a particular multicast stream as a whole. It also supports 182 measurement for a segment (i.e. a forwarding branch, a forwarding 183 node or the combination of them) of a multicast forwarding path. The 184 features enable the monitoring of a whole multicast tree, of one or 185 more forwarding paths, and of parts of the tree or path(s). 187 o Proactive and on-demand modes - It is capable of carrying out a 188 measurement session proactively or on demand according to the 189 configured management policy. 191 4. IRSM Message 193 Two IRSM message types are defined: Loss Measurement (LM) message and 194 Delay Measurement (DM) message. An example format of both LM and DM 195 messages are given in section 5.2 and 5.3 respectively. 197 4.1. Encapsulation 199 IRSM measurement messages are encapsulated in IP packets. Same SA, DA 200 and DSCP value as the multicast stream monitored are used for IRSM 201 packets. By this means, it is ensured that IRSM packets for a 202 specific (S,G) or (*,G) follow the exact same data path as user 203 traffic, i.e. fate sharing. IRSM packets can be distinguished from 204 the data traffic using a dedicated IP protocol type in IP header. In 205 another way, an UDP port number could be assigned to make this 206 identification. Using UDP port requires an intermediate MIP node to 207 look deeper into an OAM packet, which introduces additional 208 processing burden on MIP nodes. 210 The data part of an IRSM message adopts the popular Type-Length-Value 211 structure, as shown in figure 1. 213 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Type | Length | Value | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 ~ Value Continued ~ 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Figure 1. The Type-Length-Value Structure of IRSM Messages 224 Type - the type of the OAM message. 226 0, LM - Loss Measurement message 228 1, DM - Delay Measurement message 230 2-255, reserved for future use 232 Length - the length of the OAM message, not including the common IP 233 header, the Type field and the Length field. 235 Value - the content of a specific OAM messages except for the Type 236 and the Length fields. 238 4.2. Loss Measurement Message 240 An example format of LM message is shown in figure 2. 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Type = LM | Length | Version | Reserved | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Session ID | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Transmission Period | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Sequence Number | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Transmitted Packet Count | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Received Packet Count | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 ~ Optional ~ 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Figure 2. The Format of an LM Message 262 Version - The version of the message. Its current value is 0. 264 Session ID - The identification of this measurement session. 266 Transmission Period - The period of LM message within this 267 measurement session. 269 Sequence Number - A unique identification of an IRSM message. It is 270 increased by 1 when a new LM message is generated within a 271 measurement session. 273 Transmitted Packet Count - the accumulated number of data packets 274 transmitted since the last LM message was generated. This field is 275 filled by MEP-I when generating a LM message. 277 Received Packet Count - the accumulated number of received data 278 packets received by this MEP_E or MIP entity since the previous LM 279 packet was received. It is an optional field. 281 Optional - This is an optional field, which is reserved for future 282 use to carry other information (e.g., Authentication info) if needed. 284 4.3. Delay Measurement Message 286 The DM message can be defined as shown in figure 3. 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | DM Type = 1 | Length | Version | Reserved | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Session ID | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Transmission Period | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Sequence Number | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Transmission Timestamp | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Receiving Timestamp | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 ~ Optional ~ 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 3. The Format of DM message 307 The Version, Session ID, Transmission Period, and Sequence Number 308 fields have the same meaning as those defined in LM message. 310 Transmission Timestamp - The local timestamp when generating this DM 311 message. 313 Receiving Timestamp - The local timestamp when receiving this DM 314 message. This field is optional and reserved for future use. 316 Optional - This is an optional field, which is reserved for future 317 use to carry other information (e.g., Authentication info) if needed. 319 5. Principle of IRSM 321 5.1. Measurement Architecture 323 Three functional entities are defined in IRSM measurement 324 architecture: MEP-I, MIP and MEP-E[2]. They are logical entities 325 that can be configured on the incoming or outgoing interfaces of the 326 monitoring equipments. The relationship of these entities is 327 illustrated in figure 4. 329 +------+ +------+ +------+ +-------+ +------+ 330 | root <> - <>router<> - <>router<> - <>router<> - <> leaf | 331 +------+ +------+ +------+ +-------+ +------+ 332 . . . . . . . . 333 . . . . . . . . 334 . . . . . . . . 335 MEP-I MIP1 MIP2 MIP3 MIP4 MIP5 MIP6 MEP-E 337 <> Interface 338 ------ Link 340 Figure 4. The relationship of MEP and MIP entities 342 The basic function of MEP-I is to initiate a measurement session. It 343 generates OAM measurement packets for certain (S,G) or (*,G) and 344 injects it into the data traffic. The measurement session could be 345 initiated either proactively or on-demand. During a packet loss 346 measurement, MEP-I takes count of the transmitted packets from a 347 specific multicast stream and sends out the Loss Measurement (LM) 348 message along the multicast path carrying this packet count. For 349 delay measurement, MEP-I generates the Delay Measurement (DM) message 350 recording the locally generated timestamp. 352 MEP-E is the end point of the measurement path. It terminates the 353 OAM measurement packets and measures the packet loss or delay from 354 MEP-I to MEP-E. MEP-E calculates the packet loss from MEP-I 355 according to local packet count of the stream and the packet count in 356 the received LM packet sent by MEP-I, and calculates the delay from 357 MEP-I by comparing the timestamp carried in the DM message and local 358 time for receiving this message. 360 MIP entity locates between MEP-I and MEP-E and forward OAM packets 361 from upstream MEP-I to downstream MEP-E(s). It is optionally 362 configured on the intermediate node of a multicast forwarding path. 363 If MIP function is enabled on an intermediate node, it can perform 364 the measurement for a certain network segment. MIP entity snoops the 365 OAM measurement packets and calculates the packet loss and delay from 366 MEP-I to itself in the same way as an MEP-E does. 368 If MEP-I function is configured on the root node and MEP-E configured 369 on the leaf node, then the monitored path is a complete multicast 370 forward path, as depicted in figure 1. If MEP-I or MIP-E is 371 configured on an intermediate node, then part of the multicast path 372 could be monitored. 374 5.2. Packet Loss Measurement 376 Packet loss measurement could be performed proactively or on demand 377 according to the configuration of a measurement session. In 378 proactive mode, LM packet will be transmitted by MEP-I continuously 379 with a specific time interval. For on-demand mode, LM will be sent 380 periodically, or based on a pre-arranged schedule. If the schedule 381 is for a single measurement, then two LM messages are required to be 382 generated, the reason is given as below. 384 When a measurement session starts, MEP-I counts the transmitted 385 packets from a multicast data stream for a specified time interval. 386 If the timer expires, MEP-I generates an LM packet carrying this 387 transmitted packet count (say Tx_Count) of the multicast data packets 388 having been sent. The LM packet is injected into the data stream, 389 and forwarded in the same way as a real multicast data packet. 391 MEP_E counts the number of the received packet from a multicast 392 stream for a specified time (denoted as Rx_Count). The packet loss 393 is the difference between the two counters (i.e. Tx_Count - Rx_Count) 394 for this time interval. This calculation is incorrect when the 395 packet counter(s) of MEP_I and/or MEP_E wrap after reaching their 396 maximum values. Two successive measurements are used to eliminate 397 this effect, with the calculation taken as: 399 Packet Loss = (Tx_Count2 - Tx_Count1)-(Rx_Count2 - Rx_Count1) 401 Where Tx_Count1 and Tx_Count2 are respectively packet count values 402 carried in two successive packets, and Rx_Count1 and Rx_Count2 are 403 packet counts locally accumulated by MEP_E during the same time 404 interval. 406 If MIP function is enabled on an intermediate node, it will snoop the 407 measurement packets and count the received data packets locally. On 408 receiving an LM packet, it records the current local packet count 409 (say Rx_Count1') and the transmitted packet count Tx_Count1' in the 410 received LM packet. And after receiving a subsequent LM packet, it 411 takes the same action as above to acquire the local packet count (say 412 Rx_Count2') and the transmitted packet count carried in this LM 413 packet (say Tx_Count2'). The packet loss is calculated as: 415 Packet Loss = (Tx_Count2' - Tx_Count1')-(Rx_Count2' -Rx_Count1') 417 The calculation could be performed in a process component within 418 (e.g., a dedicated process component) or outside (e.g., NMS) the MIP 419 node. 421 Each MIP and MEP-E node on the path could obtain the packet loss 422 statistics of the path from MEP-I to itself by this means and both 423 per-segment and end-to-end performance monitoring are available 424 within a measurement session. The integration of the overall 425 measurement results could help to detect and locate the failure 426 point(s) and the performance bottle point(s) along the forwarding 427 path, which is shown in section 6.1. 429 5.3. Packet Delay Measurement 431 Time synchronization among the measuring entities is required for 432 packet delay measurement. The measurement process of DM is almost 433 the same as packet loss measurement. It can be operated proactively 434 or on-demand. The only difference is that the process is based on a 435 timestamp value other than a packet counter. 437 When a measurement session starts, MEP-I generates DM packets 438 carrying the local timestamps (say Tx_Time) and sends them onto the 439 multicast path. The DM packets are forwarded in the same way as the 440 normal multicast data. 442 When MEP_E receives a DM packet, it records the local timestamp that 443 identifies the arrival time of the DM packet (Rx_Time). The delay 444 measurement result could be calculated by: 446 Packet Delay = Rx_Time - Tx_Time 448 Similarly, if MIP function is enabled in an intermediate node, it 449 will snoop the DM packet to get the timestamps of the time when a DM 450 packets are sent at MEP-I. On receipt of a DM packet, the MIP node 451 records the local timestamp (say Rx_Time1) and the timestamp (say 452 Tx_Time1) carried in the DM packet. The packet delay between MEP-I 453 and MIP could be calculated as (Rx_Time1- Tx_Time1). Similar to LM 454 measurement, the calculation could be performed in a process 455 component within (e.g., a dedicated process component) or outside 456 (e.g., NMS) the MIP node. 458 Each MIP and MEP-E entity could acquire the packet delay information 459 from MEP-I to itself. By this means it is able to perform per- 460 segment and end-end delay measurement within a single measurement 461 session, which helps detection and isolation of performance defect 462 points, as shown in section 6.2 464 6. Application in multicast network monitoring 466 This section describes how packet loss measurement and packet delay 467 measurement are used in IRSM to accomplish multicast network 468 performance monitoring. To simplify the illustration, a small 469 multicast tree is depicted in figure 5. In this example, the 470 downstream interface of the root node acts as MEP-I, upstream and 471 downstream interfaces of intermediate nodes are configured as MIPs, 472 and upstream interfaces of leaf nodes are assigned as MEP-Es. 474 I +--------+ 475 +---<> Leaf 2 | 476 +----------+ G | +--------+ 477 +----------+ C E | <>----+ 478 +---#--+ A B | <>-----<> router 2 | 479 | root <>------<> router 1 | | <>----+ 480 +------+ | <>---+ +----------+ H | J +--------+ 481 . +----------+ D | +---<> Leaf 3 | 482 . . . | F +--------+ +--------+ 483 . . . +--<> Leaf 1 | . 484 . . . +--------+ . 485 . . . . . . 486 MEP-I MIP1 MIP2 MIP5 MIP6 MEP-E2 487 MIP3 MEP-E1 MIP7 MEP-E3 489 <> Interface 490 ------ Link 492 Figure 5. An example of multicast forwarding tree to be monitored 494 6.1. Fault Detection and Localization Based on LM 496 The sending and processing of LM packets by MEP and MIP enable the 497 fault detection and location for performance monitoring, both for 498 network link and network node. Suppose in figure 5, the link C-E 499 between router1 and router2 has performance bottleneck which causes 500 packet losses. Based on the principle given in section 4.2, all the 501 monitoring entities on the downstream of the link will perceive this 502 loss by packet loss calculation, while the upstream will not. 503 Because the downstream entities (i.e. MIP5, MIP6, MIP7, MEP-E2, MEP- 504 E3) will detect the packet losses, whereas the upstream entities (i.e. 505 MIP1 and MIP2) will not, it can be inferred that the link between C 506 and E is suffering from performance problem. 508 The degradation of an intermediate node can also be detected and 509 isolated in this way. For example if router2 has forwarding defect 510 which introduces packet loss, by snooping LM messages and counting 511 locally received packets, MIP6, MIP7, MEP-E2, and MEP-E3 will detect 512 the packet loss while the upstream MIP1, MIP2 and MIP5 will not. The 513 fault point of router2 will be easily located. 515 It is even possible to detect multiple point failures along the 516 multicast forwarding path, if such errors occur. In figure 5, if 517 link C-E and H-J both undergo packet losses, all the entities down 518 from the C-E will detect the defects. But as MIP7 and MEP-E3 have 519 different packet loss values from MIP5, in which case packet loss 520 detected in MIP7 and MEP-E3 are equal but are greater than those 521 measured in MIP5, then additional fault point of link H-J could be 522 easily picked out. 524 6.2. Fault Detection and Localization Based on DM 526 The fault detection and location principle of the packet delay 527 measurement is the same as that of packet loss measurement given in 528 section 6.1. If the link or node has defects that cause packet delay 529 increasing, their downstream MIPs and MEP-Es will perceive them. If 530 the delay value rises over a reasonable threshold level, then it can 531 be judged that the link or node is undergoing performance abnormities. 532 The DM could be operated to support single-point link and node 533 detection, multipoint link and node detection, as long as the 534 forwarding path is equipped with enough monitoring entities. 536 7. Deployment Considerations 538 When IRSM is deployed in practical network, many issues should be 539 considered to enable the scheme to work efficiently. Here are 540 emulated some of the key aspects that should be paid special 541 attention to when implementing IRSM. 543 7.1. Acquisition of monitored stream 545 Because LM needs to take count of the data packet from a real stream, 546 an IRSM-enabled node must provide the means to acquire the multicast 547 stream to be monitored. In practice this could be implemented by an 548 ACL method. If the stream to be monitored is specified by an (*,G) 549 or an (S,G) pair, the ACL policy could be set to permit the packets 550 belong to this stream to be processed by the IRSM module. 552 7.2. Alarm and Reporting Processing 554 The alarming and reporting method in case of abnormal and normal 555 status should be in the scope of network planning and should be 556 designed according to the local policy of the management and the 557 scale of the multicast tree. To prevent alarm and report from 558 overburdening the network and the NMS systems, the amount of these 559 messages generated should be minimized. 561 In IRSM performance monitoring, a feasible scheme is to let only the 562 MEP-E entities alarm the exception state when packet loss or 563 unacceptable packet delay is detected. MIP nodes only log the 564 exception and will only send report to the management system 565 regularly or passively in response to the queries. It needs further 566 study on how to design in detail the alarming and reporting functions 567 of an IRSM system. 569 7.3. Configuration of Monitoring Nodes 571 IRSM performance monitoring system should be flexible enough for the 572 provider to operate. For example, the provider may at this time 573 prefer proactively monitoring and in other occasions need to take 574 some discrete tests on demand. He may choose to monitor the whole 575 multicast tree, only some important forwarding paths or branches, or 576 even merely several nodes prone to performance degradation. An IRSM- 577 capable node should be able to be enabled or disabled for its 578 monitoring function as required by a configuration operation to 579 support this flexibility. 581 The configuration should also be used to provide the parameters of a 582 monitoring session, such as the OAM execution frequency, the starting 583 or ending of a monitoring session, the multicast stream to be 584 monitored, and etc. The configuration could be implemented as the 585 manual manner by an administrator, or by a control plane protocol. 586 The latter has the advantages of flexibility and scalability. It is 587 for further study on how to realize a practical configuration control. 589 7.4. Topology Discovery 591 Topology discovery is the precondition of the monitoring of a 592 multicast tree. IRSM administrator could make use of current 593 available multicast tree topology discovery tool in a multicast 594 management system. If this is unavailable, it is possible to define 595 a lightweight tool specific for IRSM uses. 597 7.5. Interoperation among Different Vendors 599 If equipments from different vendors are deployed in the same 600 multicast tree or on the same multicast forwarding path, cares should 601 be taken to interoperate them well to fulfill the performance 602 monitoring task. Because the LM and DM packets are treated normally 603 as the multicast data packets, the only interoperability requirement 604 is that those intermediate IRSM-incapable equipments do not discard 605 the LM or DM packets. 607 8. Security Considerations 609 It should be recognized that conducting performance monitoring 610 measurements can raise security concerns. IRSM system, in which 611 traffic is injected into the network, can be abused for denial-of- 612 service attacks disguised as legitimate measurement activity. 613 Authentication, authorization and encryption techniques may be used 614 where appropriate to guard against injected traffic attacks. These 615 aspects will be discussed in the future version of the memo. 617 9. IANA Considerations 619 If IP Protocol in IP header is used as the Identification of IRSM OAM 620 packets, then a new IP protocol value is required to be assigned by 621 IANA. 623 If UDP port number in UDP header is used as the identification of 624 IRSM OAM packets, then a new UDP value is required to be assigned by 625 IANA. 627 10. References 629 10.1. Normative References 631 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 632 Levels", BCP 14, RFC 2119, March 1997. 634 [2] ITU-T Recommendation Y.1731 (02/2008), " OAM functions and 635 mechanisms for Ethernet based networks ", Feb,2008. 637 10.2. Informative References 639 [3] M. Bianchetti, G. Picciano, M. Chen, and L. Zheng, " Requirements 640 for IP multicast performance monitoring ", draft-bipi-mboned-ip- 641 multicast-pm-requirement-01.txt, March 2010. 643 11. Acknowledgments 645 Special thanks should be given to Guo Xinchun and Wang Yan for their 646 valuable comments of the draft. 648 Authors' Addresses 650 Liu Hui 651 Huawei Technologies Co., Ltd. 652 Huawei Building, No.3 Xinxi Road, 653 Hai-Dian District, 654 Beijing 100085 655 China 657 Email: liuhui47967@huawei.com 659 Mach(Guoyi) Chen 660 Huawei Technologies Co., Ltd. 661 Huawei Building, No.3 Xinxi Road, 662 Hai-Dian District, 663 Beijing 100085 664 China 666 Email: mach@huawei.com 668 Lianshu Zheng 669 Huawei Technologies Co., Ltd. 670 Huawei Building, No.3 Xinxi Road, 671 Hai-Dian District, 672 Beijing 100085 673 China 675 Email: verozheng@huawei.com