One document matched: draft-zheng-pim-multicast-pm-config-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 15:46:49 |