Network working group L. Zheng Internet Draft H. Liu Intended status: Standards Track Huawei Technologies Expires: January 2011 July 5, 2010 PIM Multicast Performance Monitoring Configuration (M-PMC) Join Attribute draft-zheng-pim-multicast-pm-config-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 5, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Zheng, et al. Expires January 5, 2011 [Page 1] Internet-Draft PIM OAM Configuration Join Attribute July 2010 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This draft introduces a new type of PIM Join Attribute which carries measurement configuration TLVs, which are used for multicast performance monitoring. It is based on [RFC5384], and specifies additional procedures to process the Multicast Performance Monitoring Configuration (M-PMC) attribute to implement automatic performance monitoring configuration on multicast forwarding tree. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Table of Contents 1. Introduction.................................................2 2. Use of M-PMC Join Attribute..................................3 2.1. Overview................................................3 2.2. Sending M-PMC Join Attribute............................4 2.3. Receiving M-PMC Join Attribute..........................5 2.4. Conflict Resolution.....................................6 2.5. Configuration Failure...................................7 3. Packet Format................................................7 3.1. PIM M-PMC Join Attribute Format.........................7 3.2. Configuration TLV Format................................8 3.3. PIM M-PMC Hello Option..................................9 4. Security Considerations.....................................10 5. IANA Considerations.........................................10 6. Acknowledgments.............................................10 7. References..................................................10 7.1. Normative References...................................10 Authors' Addresses.............................................11 1. Introduction Service Providers have been leveraging IP multicast to provide revenue-generating services, such as IP television (IPTV), video conferencing, as well as the distribution of stock quotes or news. These services are usually loss-sensitive or delay-sensitive, and their data packets need to be delivered over a large scale IP Zheng, et al. Expires January 5, 2011 [Page 2] Internet-Draft PIM OAM Configuration Join Attribute July 2010 network in real-time. Providing monitoring support for multicast is important for building robust multicast services. This draft introduces a new type of PIM Join Attribute which carries measurement configuration TLVs, which are used for multicast performance monitoring. It is based on [RFC5384], and specifies additional procedures to process the Multicast Performance Monitoring Configuration (M-PMC) attribute to implement automatic performance monitoring configuration on multicast forwarding tree. 2. Use of M-PMC Join Attribute 2.1. Overview This draft introduces a Multicast Performance Monitoring Configuration (M-PMC) Join Attribute used for multicast performance monitoring configuration. When network management personnel want to initiate a measurement session for a certain multicast group on a certain multicast forwarding path, e.g. a packet loss measurement, he could initiate the configuration on the leaf router through Command Line Interface or network management protocol and other control protocol. Configuration TLVs for different measurement entities will be included in the M-PMC attribute by the leaf router, and sent hop-by-hop towards the upstream router and the root (either the source or RP router) along the multicast tree. When upstream router receives the Join message, it will examine the attribute and determine which Configuration TLV to apply. It may also either pass the attribute upwards as is or remove some of the TLVs from the attribute, or even remove the whole attribute from the Join message and not passing further upwards. Section 2.2 to 2.5 specifies the procedures to process the M-PMC attribute when sending and receiving Join message, and to resolve the configuration conflict and failure. Figure 1 illustrates a small multicast tree to be monitored; three functional entities are defined for performance monitoring [Y.1731]: MEP_I (Maintenance Entity Group End Point Ingress), MIP (Maintenance Entity Group Intermediate Point) and MEP-E (Maintenance Entity Group End Point Egress). They are logical entities that can be configured on the upstream or downstream interfaces of the monitoring equipments. In this example, downstream interface of the root node is configured as MEP_I, upstream and downstream interfaces of intermediate nodes are configured as MIPs, and upstream interfaces of leaf nodes are configured as MEP_Es. Zheng, et al. Expires January 5, 2011 [Page 3] Internet-Draft PIM OAM Configuration Join Attribute July 2010 I +--------+ +---<> Leaf 2 | +----------+ G | +--------+ +----------+ C E | <>----+ +------+ A B | <>-----<> Router 2 | | Root <>------<> Router 1 | | <>----+ +------+ | <>---+ +----------+ H | J +--------+ . +----------+ D | +---<> Leaf 3 | . . . | F +--------+ +--------+ . . . +--<> Leaf 1 | . . . . +--------+ . . . . . . . MEP_I MIP1 MIP2 MIP5 MIP6 MEP_E2 MIP3 MEP_E1 MIP7 MEP_E3 <> Interface ------ Link Figure 1. An example of multicast forwarding tree to be monitored Three types of configuration TLVs are defined for different functional entities; they are MEP_E Configuration TLV, MEP_I Configuration TLV and MIP Configuration TLV for MEP_E, MEP_I and MIP entity configuration respectively. Network management personnel could make their own decision to include which TLV in the attribute, depending on the monitoring requirement. In each Configuration TLV, different measurement function information could be carried. Network management personnel could e.g. either enable a packet delay measurement function on the upstream interface of an intermediate node, or set up the OAM packet sending period at the MEP_E. See section 3.1 and 3.2 for the format of M-PMC Join Attribute and different type of Configuration TLVs. 2.2. Sending M-PMC Join Attribute If the leaf router is initiated for configuration, it will include the M-PMC Join Attribute when sending a PIM Join message. Configuration TLVs for different measurement entities will be included in the attribute, and sent hop-by-hop towards the upstream router and the root (either the source or RP router) along the multicast tree. Not all types of TLV need to present in the attribute, but at least MEP_I Configuration TLV will present. See Zheng, et al. Expires January 5, 2011 [Page 4] Internet-Draft PIM OAM Configuration Join Attribute July 2010 section 3.1 and 3.2 for the format definitions of M-PMC Join Attribute and different type of Configuration TLVs. If the leaf router itself is configured as MEP_E, then the MEP_E Configuration TLV MUST NOT be included in the attribute. The MEP_E Configuration TLV MUST be included in the attribute when a non-leaf node on the multicast path is assigned as MEP_E. In this case the interface address of that node will be included in the MEP_E Configuration TLV. 2.3. Receiving M-PMC Join Attribute When processing a received PIM Join that contains an M-PMC Attribute, a router MUST first check to see if the MEP_E Configuration TLV is present. If so, it MUST then check to see if the Configuration Interface Address in the TLV is one of its own IP addresses. If so, it will apply the configurations described in this TLV to its upstream and/or downstream interfaces. The MEP_E TLV is then removed from the attribute, and not passed further upstream. If the Configuration Interface Address is not any of its own IP address, none of the TLVs will be applied and the attribute will be kept the same and passed along when a PIM Join is sent upstream. If no MEP_E Configuration TLV is present, a router MUST then check to see if the Configuration Interface Address in the MEP_I Configuration TLV is one of its own IP addresses. If so, the MEP_I Configuration TLV will be applied and the whole attribute is then removed from the Join message, not passed further upstream. If the Configuration Interface Address is not any of its own IP address, the MIP TLV will be applied when it is present. Otherwise, no TLV will be applied and the attribute will be kept the same and passed along when a PIM Join is sent upstream. Zheng, et al. Expires January 5, 2011 [Page 5] Internet-Draft PIM OAM Configuration Join Attribute July 2010 +-----------------------------+-----------------+------------------+ | MEP_E TLV | MEP_I TLV | MIP TLV | +-------+------+--------------+------+----------+-------+----------+ |Present|If Add| Action |If Add| Action |Present| Action | +-------+------+--------------+------+----------+-------+----------+ | Yes | Yes | Apply/Remove | - | Not Apply| - | Not Apply| +-------+------+--------------+------+----------+-------+----------+ | Yes | No |Not Apply/Keep| - | Not Apply| - | Not Apply| +-------+------+--------------+------+----------+-------+----------+ | No | - | - | Yes | Apply | - | Not Apply| +-------+------+--------------+------+----------+-------+----------+ | No | - | - | No | Not Apply| Yes | Apply | +-------+------+--------------+------+----------+-------+----------+ Figure 2: Configuration action when receiving M-PMC Join Attribute in tabular form 2.4. Conflict Resolution On an upstream router, a conflict occurs when it has received different PIM M-PMC attributes from Join packets sent by its downstream routers. As an example, considering Figure 1 and suppose a M-PMC Join Attribute is used to configure the packet loss measurement function. There are 2 receivers for the same group connected to Leaf2 and Leaf3 respectively. Suppose Leaf2 wants to enable all the nodes on its forwarding path this function and Leaf3 wants to disable all the nodes on its forwarding path the same function. If both Leaf2 and Leaf3 send a Join including an attribute indicating their configuration to their upstream router Router2, Router2 will get conflicting attribute. If this happens, Router2 SHOULD try to merge the different attributes. The upstream interface E and downstream interface G should be enabled for packet loss measurement function, and another downstream interface H should be disabled for this function. An emerged attribute of enabling the function will be and included passed along when a PIM Join is sent upstream. In any case if a branching point router fails to merge the conflicting attributes, no more attribute should be passed further upstream and the configuration is halted. An alert should be sent to the NMS immediately. This could be done by a mechanism provided by NMS and is out of scope of this draft. Zheng, et al. Expires January 5, 2011 [Page 6] Internet-Draft PIM OAM Configuration Join Attribute July 2010 2.5. Configuration Failure In any case if a node on the multicast forwarding path fails to perform the configuration indicating by the M-PMC attribute, no more attribute should be passed further upstream and the configuration is halted. An alert should be sent to the NMS immediately. It could be done by a mechanism provided by NMS and is out of scope of this draft. 3. Packet Format 3.1. PIM M-PMC Join Attribute Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|E| Attr_Type | Length | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MEP_E Configuration TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MEP_I Configuration TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MIP Configuration TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - F bit: As specified by [RFC5384] - S bit: As specified by [RFC5384] - Attr_Type: 4 - Length: As specified by [RFC5384] - Version: The version of the attribute, current value is 0 - MEP_E Configuration TLV: TLV used for MEP_E configuration - MEP_I Configuration TLV: TLV used for MEP_I configuration - MIP Configuration TLV: TLV used for MIP configuration Zheng, et al. Expires January 5, 2011 [Page 7] Internet-Draft PIM OAM Configuration Join Attribute July 2010 3.2. Configuration TLV Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Configuration Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Fun 1 Con Type | Fun 1 Con If | Fun 1 Optional Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Fun 1 Optional Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Fun 2 Con Type | Fun 2 Con If | Fun 2 Optional Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Fun 2 Optional Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 1-octet, specifying the configuration TLV type. - 1: MEP_E Configuration TLV - 2: MEP_I Configuration TLV - 3: MIP Configuration TLV - Length: 1-octet, specifying the length in octets of the value field. Configuration values for different measurement function could be included in the same TLV. Fun Con Type field and Fun Con If field, denoted as (Fun Con Type, Fun Con If), are used together to indicate enabling or disabling corresponding function on upstream or/and downstream interfaces of the node. Flags are used to indicate the measurement functions to be configured. When set, there will be corresponding (Fun Con Type, Fun Con If) included in the TLV. - Flags: 2-octets, including 16 1-bit flags, each is defined indicating the measurement functions to be configured - 1rst bit: Packet Loss measurement indication. When set, there is (Fun Con Type, Fun Con If) for packet Loss measurement is included in the TLV. When cleared, there is no (Fun Con Type, Fun Con If) for packet Loss measurement Zheng, et al. Expires January 5, 2011 [Page 8] Internet-Draft PIM OAM Configuration Join Attribute July 2010 - 2nd bit: Packet Delay measurement indication - 3rd bit to 16th bit: Reserved for indication for other measurement functions which are not defined here at this moment - Configuration Interface Address: 4-octets, specifying the interface address of the node which is assigned as MEP_E when included in MEP_E Configuration TLV. Specifying the interface address of the node which is assigned as MEP_I when included in MEP_I Configuration TLV. SHOULD NOT present in MIP Configuration TLV - Fun Con Type: 1-octet, function configuration type. - 1: Enable - 2: Disable - Fun Con If: 1-octet, function configuration interface, specifying which interface to apply the configuration. - 1: Upstream interface - 2: Downstream interface - 3: Both upstream interface and downstream interface - Fun Optional Length: 2-octets, specifying the length in octets of the additional configuration value field. Set to zero when no additional configuration value is included. - Fun Optional Value: Optional, indicating additional configuration value for corresponding function, e.g. the OAM packet sending period at the MEP_I. Semantics is not defined at this moment. 3.3. PIM M-PMC Hello Option A router MUST include PIM M-PMC Hello Option in its PIM Hello packets if it supports this draft. The format of the Option TLV is defined to be: Zheng, et al. Expires January 5, 2011 [Page 9] Internet-Draft PIM OAM Configuration Join Attribute July 2010 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType | OptionLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - OptionType:39 - OptionLength:0 4. Security Considerations As a new type of PIM Join Attribute, the security considerations described in [RFC5384] apply here. 5. IANA Considerations A new PIM Hello Option type needs to be assigned. 39 is proposed for now. A new PIM Join Attribute type needs to be assigned. 4 is proposed for now. 6. Acknowledgments Special thanks should be given to the ones who provide valuable comments on the work. 7. References 7.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC5384] A. Boers, I. Wijnands, E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, November 2008. [Y.1731]ITU-T Recommendation Y.1731 (02/2008), " OAM functions and mechanisms for Ethernet based networks ", Feb,2008. Zheng, et al. Expires January 5, 2011 [Page 10] Internet-Draft PIM OAM Configuration Join Attribute July 2010 Authors' Addresses Lianshu Zheng Huawei Technologies Co., Ltd. Huawei Building, No.3 Xinxi Road, Hai-Dian District, Beijing 100085 China Email: verozheng@huawei.com Liu Hui Huawei Technologies Co., Ltd. Huawei Building, No.3 Xinxi Road, Hai-Dian District, Beijing 100085 China Email: liuhui47967@huawei.com Zheng, et al. Expires January 5, 2011 [Page 11]