One document matched: draft-swallow-mpls-mcast-cv-00.txt
Network Working Group George Swallow
Internet Draft Cisco Systems, Inc.
Category: Standards Track
Expiration Date: April 2007
Thomas D. Nadeau
Cisco Systems, Inc.
Rahul Aggarwal
Juniper Networks, Inc.
October 2006
Connectivity Verification for Multicast Label Switched Paths
draft-swallow-mpls-mcast-cv-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
Requirements for MPLS P2MP LSPs extend to hundreds or even thousands
of endpoints. This document defines a more scalable approach to
verifying connectivity for P2MP LSPs.
Swallow, et al. Standards Track [Page 1]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt October 2006
Contents
1 Introduction .............................................. 3
1.1 Conventions ............................................... 3
2 Overview .................................................. 3
3 Connectivity Verification Bootstrapping and Maintenance ... 4
3.1 Bootstrap and Maintenance Procedures at the Root .......... 4
3.1.1 Special Considerations for RSVP-TE P2MP Tunnels ........... 5
3.1.2 Special Considerations for mLDP P2MP Tunnels .............. 6
3.2 Procedures at an Egress ................................... 6
3.2.1 Creating Egress Connectivity Verification State ........... 6
3.2.2 Updating Egress Connectivity Verification State ........... 7
3.2.3 CV ........................................................ 7
4 Connectivity Verification Session Object .................. 7
4.1 IPv4 Connectivity Verification Session Object ............. 7
4.1.1 Included IPv4 Nodes ....................................... 8
4.1.2 Excluded IPv4 Nodes ....................................... 9
4.1.3 Administratively Down IPv4 Nodes .......................... 9
4.2 IPv6 Connectivity Verification Session Object ............. 10
4.2.1 Included IPv6 Nodes ....................................... 11
4.2.2 Excluded IPv6 Nodes ....................................... 11
4.2.3 Administratively Down IPv6 Nodes .......................... 12
5 Security Considerations ................................... 12
6 IANA Considerations ....................................... 13
7 Acknowledgments ........................................... 13
8 References ................................................ 13
8.1 Normative References ...................................... 13
8.2 Informative References .................................... 14
9 Authors' Addresses ........................................ 14
Swallow, et al. Standards Track [Page 2]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt October 2006
1. Introduction
Requirements for Multi-protocol Label Switching (MPLS) Point-to-mul-
tipoint (P2MP) Label Switched Paths (LSPs) call for scaling up to
hundreds or even thousands of endpoints. Existing tools such as
those defined in [RFC4379] and [MPLS-BFD] generally require explicit
acknowledgment to each connectivity probe. Such explicit acknowledg-
ments adversely affect the scalability and/or practicality of per-
forming connectivity verification. That is, the response load at the
root would either be overwhelming unless the probing was done infre-
quently. This document defines a more scalable approach to monitor-
ing P2MP LSP connectivity.
MPLS Echo Request/Reply messages [RFC4379] are used to bootstrap a
Bi-directional Forwarding Detection (BFD) session across the P2MP LSP
in a manner similar to "BFD For MPLS LSPs" [MPLS-BFD]. The actual
monitoring uses extensions to BFD defined in [BFD-MCST].
1.1. Conventions
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 [KEYWORDS].
Based on context the terms leaf, egress and receiver are used some-
what interchangeably. The first two are exactly the same. Egress is
used where consistency with [RFC4379] was deemed appropriate.
Receiver is used in the context of receiving protocol messages.
2. Overview
In order to scale to large numbers of leaves and to be able to verify
connectivity on a frequent basis the protocol defined herein uses BFD
packets as unidirectional probes. As specified in [BFD-MCST] BFD
packets are sent by the root at a fixed minimum interval. The leaves
receive BFD packets and declare a connectivity fault if more than a
fixed number of BFD messages are missed.
The session is bootstrapped by an MPLS Echo Request/Reply message
exchange. The root periodically sends MPLS Echo Request messages
containing a Connectivity Verification Session object which is
defined in section 3.1. The Echo Request message contains a FEC
stack to identify the LSP. This serves to bind the FEC to a BFD dis-
criminator.
Swallow, et al. Standards Track [Page 3]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt October 2006
Further discussion on the necessity of bootstrapping the BFD session
with with MPLS Echo Request/Reply messages can be found in section
3.2 of [MPLS-BFD].
3. Connectivity Verification Bootstrapping and Maintenance
The root of the multicast tree initiates Connectivity Verification
and is responsible for most of the parameters involved in the Connec-
tivity Verification Session. These parameters are communicated both
through MPLS echo request messages and through BFD. The primary role
of of the echo request message is to provide the binding between the
root's address and chosen BFD discriminator and a particular FEC. It
further enables the root to scope the session to a subset of leaves.
It also provides a facility for declare some leaves administratively
down while maintaining the CV session for the balance of the leaves.
The balance of the session parameters are communicated through BFD.
3.1. Bootstrap and Maintenance Procedures at the Root
The root first selects a discriminator and an IP destination address
to be used both in the BFD packets and in the Connectivity Verifica-
tion Session object. Prior to sending an MPLS Echo Request message,
the root SHOULD begin sending BFD packets with the selected Discrimi-
nator in the My Discriminator field and destination IP address in-
band of the subject LSP. Failure to do this could result in false
alarms.
The root then bootstraps the CV Sessions by creating an MPLS Echo
Request message containing a Connectivity Verification Session object
and a FEC stack which specifies the LSP for which connectivity veri-
fication is desired. The Connectivity Verification Session object
MUST contain the selected discriminator and destination IP address.
For IPv4 the address MUST be in the range 127/8; for IPv6 the address
MUST be in the range 0:0:0:0:0:FFFF:127/104.
The Lifetime SHOULD be set to a relatively large value as compared to
the BFD Detect Time.
The CV Session MAY be scoped to a subset of leaves by including one
of either the Excluded Nodes or Included Nodes sub-object.
Echo reply messages can be jittered by using the Echo Jitter object
defined in [[MCSTPING]. the jitter time is set to value that is a
function of the rate at which the root is able to process responses
Swallow, et al. Standards Track [Page 4]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt October 2006
and the expected number of responders to this particular message.
Exactly how values are chosen is implementation and platform depen-
dent. As such, the exact setting of this interval is beyond the
scope of this document.
The source and destination IP address of the MPLS echo request packet
MUST be the same as those used in the BFD packets. The message is
then sent in-band of the LSP.
The root (assuming the root does not want the session to time-out)
MUST refresh the session within Lifetime milliseconds. It is RECOM-
MENDED that the root refresh the CV Session at approximately one
third of the Lifetime.
If the root wishes to increase the Lifetime, it should behave as if
it were first bootstrapping the session. That is it should seek Echo
reply messages from all receivers.
If the entire CV Session is administratively taken down, this SHOULD
be handled through BFD. If, however, a subset of the egress nodes is
to be administratively taken down, this is accomplished by including
the Administratively Down Nodes sub-object listing the subject nodes.
This list may be modified on any refresh message to indicate addi-
tional nodes being taken down or to indicate certain nodes as no-
longer administratively down. Note that refresh messages MAY be sent
at any time to accomplish this.
3.1.1. Special Considerations for RSVP-TE P2MP Tunnels
For RSVP P2MP tunnels the root knows all of the leaves. When boot-
strapping a session, the root can know when all the leaves have
responded. Suppose that an initial bootstrap message has been sent
and sufficient time for responses have been allowed. If the root has
not received MPLS Echo Reply messages from all of the leaves, the
root MAY send a subsequent bootstrap message immediately using the
scoping techniques of [MCSTPING] to limit the responses.
If a new leaf is added to the tree, the root MAY send a refresh mes-
sage immediately. Further it MAY use the scoping techniques of
[MCSTPING] to limit the response to just the new leaf.
Swallow, et al. Standards Track [Page 5]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt October 2006
3.1.2. Special Considerations for mLDP P2MP Tunnels
For Multicast LDP P2MP tunnels the root generally does not know all
of the leaves. It is therefore RECOMMENDED that the initial boot-
strapping messages be retransmitted at Detection_Multiple times at a
relatively short intervals.
Note that the root can learn who the leaves are from the MPLS Echo
Reply messages. It is RECOMMENDED that the root keep a list of
active leaves. When the any of the parameters in section 3.2 above
are changed, the root can then use the technique in section 3.2.1 to
ensure that state is updated, noting however, that some leaves may
have ceased connectivity to the tree, while others may have joined.
3.2. Procedures at an Egress
[Note: this section needs to be brought into in sync with [BFD-MCST]]
BFD packets addressed to IPv4 addresses in the range 127/8 or IPv6
addresses in the range 0:0:0:0:0:FFFF:127/104 should be ignored if no
MPLS Echo Request has been received containing the associated IP
source address and discriminator combination.
When a node receives a MPLS Echo Request containing a Connectivity
Verification object, it begins by processing the message as it would
any other MPLS Echo Request message. If the result of that process-
ing is that the node is an egress for the FEC at the bottom of the
FEC stack, it checks to see if it has state matching the source IP
address, discriminator and FEC stack. If not it creates state as
specified in section 3.2.1 below. If it does it updates that state
as specified in section 3.2.2. Normal response processing for the
received MPLS Echo is then done.
3.2.1. Creating Egress Connectivity Verification State
If the message contains an Included Nodes sub-object which does not
list the egress or contains an Excluded Nodes sub-object which lists
the egress, no action is taken. Otherwise, state is created keyed on
the source IP address and Discriminator value. This state is set to
expire in Lifetime milliseconds. The session is considered to have
expired if not refreshed prior to the expiration of this timer.
Included in this state is the FEC and CV Session state, initially set
to Init. The egress SHOULD now process BFD packets with this source
IP address and Discriminator value.
When a BFD packet is received that matches the source IP address and
Swallow, et al. Standards Track [Page 6]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt October 2006
Discriminator it is processed and a BFD session is created. The BFD
session is linked to this CV state. In particular the CV session is
informed of the BFD state transitions. The CV Session state is
changed to UP.
3.2.2. Updating Egress Connectivity Verification State
[Note, this section will be updated when the CV Session State Machine
is added].
If an Connectivity Verification Session object is received which
matches the Source_IP_Addr, Discriminator and FEC Stack of existing
CV state the Lifetime is reset and the message is examined to deter-
mine if there have been any changes in parameters. If the IP address
of the egress has been added to the Administratively down nodes, the
egress MUST change the CV session state to Administratively Down.
If the IP address of the egress has been removed from the Administra-
tively Down nodes, then if the BFD session state is Down or the BFD
session has been deleted, the CV state is set to INIT; if the BFD
session state is UP the CV session state is set to UP.
If the egress has been removed from the Included Nodes sub-object or
added to the Excluded Nodes sub-object then the BFD session is termi-
nated and the Connectivity Verification state is removed.
3.2.3. CV Session State Machine
[To be written]
4. Connectivity Verification Session Object
The Connectivity Verification Session object is used to notify leaves
that connectivity verification will be performed on the LSP and to
set the connectivity verification parameters.
4.1. IPv4 Connectivity Verification Session Object
The IPv4 Connectivity Verification Session object has the following
format:
Swallow, et al. Standards Track [Page 7]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt October 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs |
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Discriminator
The unique, nonzero discriminator value generated by the
transmitting system, which will be used to identify this BFD
session.
Destination Address
The IPv4 Destination Address that will be used in the BFD
packets sent. Normally this is an address from the range 127/8.
Lifetime
This is the minimum period before a refresh message is sent in
milliseconds.
Sub-TLVs
Three sub-TLVs are defined
Sub-Type Length Value Field
-------- ------ -----------
1 4+ Included IPv4 Nodes
2 4+ Excluded IPv4 Nodes
3 4+ Administratively Down IPv4 Nodes
4.1.1. Included IPv4 Nodes
The Included IPv4 Nodes sub-object scopes to message to bootstrap all
nodes listed in the Included IPv4 Nodes sub-object. This sub-object
MUST NOT be used in combination with the Excluded IPv4 Nodes sub-
object.
Swallow, et al. Standards Track [Page 8]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt October 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional IPv4 Address |
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.2. Excluded IPv4 Nodes
The Excluded IPv4 Nodes sub-object scopes the message to bootstrap
all nodes not listed in the Excluded IPv4 Nodes sub-object. This
sub-object MUST NOT be used in combination with the Included IPv4
Nodes sub-object.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional IPv4 Address |
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.3. Administratively Down IPv4 Nodes
The Administratively Down IPv4 Nodes sub-object is used to suppress
alarms from specific nodes.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional IPv4 Address |
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Swallow, et al. Standards Track [Page 9]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt October 2006
4.2. IPv6 Connectivity Verification Session Object
The IPv6 Connectivity Verification Session object has the following
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Destination Address |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs |
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Discriminator
The unique, nonzero discriminator value generated by the
transmitting system, which will be used to identify this BFD
session.
Destination Address
The IPv6 Destination Address that will be used in the BFD
packets sent. Normally this is an address from the range
0:0:0:0:0:FFFF:127/104.
Lifetime
This is the minimum period before a refresh message is sent in
milliseconds.
Swallow, et al. Standards Track [Page 10]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt October 2006
Sub-TLVs
Three sub-TLVs are defined
Sub-Type Length Value Field
-------- ------ -----------
1 16+ Included IPv6 Nodes
2 16+ Excluded IPv6 Nodes
3 16+ Administratively Down IPv6 Nodes
4.2.1. Included IPv6 Nodes
The Included IPv6 Nodes sub-object scopes to message to bootstrap all
nodes listed in the Included IPv6 Nodes sub-object. This sub-object
MUST NOT be used in combination with the Excluded IPv6 Nodes sub-
object.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional IPv6 Address |
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2.2. Excluded IPv6 Nodes
The Excluded IPv6 Nodes sub-object scopes the message to bootstrap
all nodes not listed in the Excluded IPv6 Nodes sub-object. This
sub-object MUST NOT be used in combination with the Included IPv6
Nodes sub-object.
Swallow, et al. Standards Track [Page 11]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt October 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional IPv6 Address |
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2.3. Administratively Down IPv6 Nodes
The Administratively Down IPv6 Nodes sub-object is used to suppress
alarms from specific nodes.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional IPv6 Address |
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. Security Considerations
Security considerations discussed in [BFD], [BFD-MHOP] and
[RFC4379]
apply to this document.
Swallow, et al. Standards Track [Page 12]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt October 2006
6. IANA Considerations
This document makes the following codepoint assignments from the LSP
Ping Object Type registry (pending IANA action):
Object Codepoint
Sub-object
IPv4 Connectivity Verification Session tba
Included IPv4 Nodes 1
Excluded IPv4 Nodes 2
Administratively Down IPv4 Nodes 3
IPv6 Connectivity Verification Session tba
Included IPv6 Nodes 1
Excluded IPv6 Nodes 2
Administratively Down IPv6 Nodes 3
7. Acknowledgments
The authors would like to thank Dave Katz, Dave Ward, and Vanson Lim
for their comments and suggestions.
8. References
8.1. Normative References
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[BFD-MCST] Katz, D. and D. Ward, "BFD for Multipoint and Multicast
Networks", draft-katz-ward-bfd-multipoint-00.txt, October
2006.
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding
Detection", draft-ietf-bfd-base-05.txt, June 2006.
[BFD-MHOP] D. Katz, D. Ward, "BFD for Multihop Paths",
draft-ietf-bfd-multihop-04.txt, June 2006.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MCSTPING] Farrel, A. et al, "Detecting Data Plane Failures in
Swallow, et al. Standards Track [Page 13]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt October 2006
Point-to-Multipoint MPLS Traffic Engineering -
Extensions to LSP Ping",
draft-ietf-mpls-p2mp-lsp-ping-02.txt, September 2006.
8.2. Informative References
[MPLS-BFD] Aggarwal, R., et al., "BFD For MPLS LSPs",
draft-ietf-bfd-mpls-03.txt, June 2006.
9. Authors' Addresses
George Swallow
Cisco Systems, Inc.
Email: swallow@cisco.com
Tom Nadeau
Cisco Systems, Inc.
Email: tnadeau@cisco.com
Rahul Aggarwal
Juniper Networks, Inc.
Email: rahul@juniper.net
Copyright Notice
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Expiration Date
April 2007
Swallow, et al. Standards Track [Page 14]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt October 2006
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Swallow, et al. Standards Track [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-21 23:01:53 |