The MPLS WG Archive
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index][Thread Index][Author Index][Subject Index]
[mpls] George Swallow: Please post the enclosed mcast ping draft
-
From: George Swallow <swallow@cisco.com>
-
Date: Tue, 20 Jun 2006 13:04:40 -0400
-
X-IronPort-AV: i="4.06,157,1149480000"; d="scan'208"; a="90589143:sNHT54461948"
-
X-OriginalArrivalTime: 20 Jun 2006 17:03:40.0030 (UTC)FILETIME=[7A5391E0:01C6948B]
Folks -
I was running off to my niece's wedding when I tried to post this.
But as you can see I didn't type the whole address.
I'll put it on the MPLS agenda time permitting.
...George
-
From: George Swallow <swallow@cisco.com>
-
Date: Sat, 17 Jun 2006 17:36:04 -0400
-
Cc: tnadeau
thanks,
...George
========================================================================
Network Working Group George Swallow
Internet Draft Cisco Systems, Inc.
Category: Standards Track
Expiration Date: December 2006
Tom Nadeau
Cisco Systems, Inc.
June 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. Note that while this approach
was developed in response to the multicast scalability problem, it
can be applied to P2P LSPs as well.
Swallow & Nadeau Standards Track [Page 1]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006
Contents
1 Introduction .............................................. 3
1.1 Conventions ............................................... 3
1.2 Terminology ............................................... 3
2 Overview .................................................. 3
3 Connectivity Verification Bootstrapping ................... 4
3.1 Connectivity Verification Session Object .................. 4
3.2 Bootstrap and Maintenance Procedures at the Root .......... 5
3.2.1 Special Considerations for RSVP-TE P2MP Tunnels ........... 6
3.2.2 Special Considerations for mLDP P2MP Tunnels .............. 6
3.3 Bootstrapping Proceedures at an Egress .................... 7
3.3.1 Creating Egress Connectivity Verification State ........... 7
3.3.2 Updating Egress Connectivity Verification State ........... 7
4 MPLS Connectivity Verification Probing .................... 8
4.1 MPLS Connectivity Verification Probe ...................... 8
4.2 Sending MPLS Connectivity Verification Probes ............. 9
4.3 Receiving MPLS Connectivity Verification Probes ........... 9
4.4 MPLS Connectivity Verification UDP Port ................... 9
5 Multicast LDP FEC Stack Sub-object ........................ 9
6 Security Considerations ................................... 11
7 IANA Considerations ....................................... 11
8 Acknowledgments ........................................... 11
9 References ................................................ 11
9.1 Normative References ...................................... 11
9.2 Informative References .................................... 12
10 Authors' Addresses ........................................ 12
Swallow & Nadeau Standards Track [Page 2]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006
1. Introduction
Requirements for MPLS P2MP LSPs extend to hundreds or even thousands
of endpoints. If a protocol required explicit acknowledgments to
each probe for connectivity verification, the response load at the
root would be overwhelming.
This document defines a more scalable approach to monitoring P2MP LSP
connectivity. Note that while this approach was developed in
response to the multicast scalability problem, it can be applied to
P2P LSPs as well.
MPLS Echo Request/Response messages [RFC4379] are used to bootstrap
the monitoring mechanism in a manner similar to "BFD For MPLS LSPs"
[MPLS-BFD]. The actual monitoring is done with MPLS Connectivity
Verification Probes, which are defined herein.
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].
1.2. Terminology
Although the techniques of this document may be applied to P2P LSPs,
terms applicable to P2MP LSPs are used throughout. Based on context
the terms leaf, egress and receiver are used somewhat interchange-
ably. The first two are exactly the same. Egress is used where con-
sistency 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 uses a unidirectional
probe. The probe message, the MPLS Connectivity Verification Probe,
is defined in section 4.1. Probes are sent by the root at a fixed
minimum interval. The leaves receive probes and declare a connectiv-
ity fault if more than a fixed number of probe messages are missed.
Probing is discussed in section 4.
The session is bootstrapped with MPLS Echo Request/Response messages.
Swallow & Nadeau Standards Track [Page 3]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006
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 also contains a FEC stack to identify
the LSP. For mLDP P2MP LSPs a new FEC sub-TLV is defined in section
5. Bootstrapping is discussed in section 3.
3. Connectivity Verification Bootstrapping
Bootstrapping is accomplished by sending an MPLS Echo Request message
containing a Connectivity Verification Session object and a FEC stack
which specifies the LSP for which connectivity verification is
desired. The next section describes the Connectivity Verification
Session object. Subsequent sections describe the procedures for the
root and leaves.
3.1. Connectivity Verification Session Object
The Connectivity Verification Session object is used to notify the
receivers that connectivity verification will be performed on the LSP
and to set the connectivity verification parameters.
The Connectivity Verification Session object has the following for-
mat:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Detect Mult |A|F| MUST Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min CV TX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response Jitter Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Detect Mult
Detection multiplier. The Min_TX_Interval multiplied by this
value, provides the Detection_Time for the receivers.
Swallow & Nadeau Standards Track [Page 4]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006
Administratively Down (A)
This flag indicates that the connectivity verification session
is administratively down. This permits the session to be
quieced without alarming.
Forward Defect (F)
This flag indicates a defect upstream of the LSP. It MAY be set
in order to suppress alarms downstream of the LSP.
Discriminator
A unique, nonzero discriminator value generated by the
transmitting system, used to demultiplex multiple BFD sessions
between the same pair of systems.
Min TX Interval
This is the minimum interval, in microseconds, that the source
system will use when transmitting Connectivity Verification
Probes.
Refresh Interval
This is the minimum period before a refresh message is sent in
milliseconds.
Response Jitter Interval
The interval over which MPLS Echo Reply messages are to be
randomly delayed in milliseconds.
3.2. Bootstrap and Maintenance Procedures at the Root
The root initiates bootstrapping by sending an MPLS Echo Request mes-
sage containing a Connectivity Verification Session object and a FEC
stack which specifies the LSP for which connectivity verification is
desired.
The Refresh Interval is set to a relatively long value. The root
MUST refresh the session within this interval. The root MAY jitter
refresh messages but the Refresh Interval serves as a hard upper
bound on the jittering. MPLS Echo Requests which refresh the CV Ses-
sion SHOULD be sent on average at approximately one third of the
Refresh Interval.
Swallow & Nadeau Standards Track [Page 5]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006
The Response Jitter Interval is set to value that is a function of
the rate at which the root is able to process responses and the
expected number of responders to this particular message. Exactly
how values are chosen is implementation and platform dependent. As
such, the exact setting of this interval is beyond the scope of this
document.
Together the Min TX Interval, the Detection Multiplier determines the
maximum amount of time it will take for a fault to be declared.
Appropriate values should be chosen. The suggested default value for
the Detection Multiplier is 3.
When any of the following conditions apply, the root should behave as
if it were first bootstrapping the session. That is it should seek
Echo Responses from all receivers. It this is not possible, for
example, because the subject P2MP LSP needs to be removed quickly,
then Detection_Multiple MPLS Echo Request messages SHOULD be sent
prior to effecting the change.
Changing the Discriminator
Decreasing the Detection Multiplier
Increasing the Minimum_Tx_Interval
Increasing the Refresh_Interval
Ceasing the transmission of CV Probe messages subsequent to
signaling "Administratively Down"
3.2.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 Response 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.
3.2.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 3 times at a relatively short
interval.
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
Swallow & Nadeau Standards Track [Page 6]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006
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.3. Bootstrapping Proceedures at an Egress
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 and FEC stack. If not it creates state as specified in sec-
tion 3.3.1 below. If it does it updates that state as specified in
section 3.3.2.
3.3.1. Creating Egress Connectivity Verification State
State is created keyed on the source IP address and Discriminator
value. The lifetime for this state is set to expire in
Refresh_Interval milliseconds. The session is considered to have
expired if not refreshed prior to the expiration of this timer.
The Detection_Time is calculated equal to the value of Detection_Mul-
tiplier times the Min_TX_Interval. The Detection_Multiplier value is
(roughly speaking, due to jitter) the number of packets that have to
be missed in a row to declare the session to be down.
A Detection_Timer is created, which upon expiration will invoke
detection notification. The timer is set to the Detection_Time. If
the Administratively Down flag is not set, the timer is started.
If the Forward Defect Flag is set, an up call to any registered
applications is made.
An MPLS Echo Reply message is sent as normal, except that it is
delayed by the Response_Jitter_Interval times a random number between
zero and one.
3.3.2. Updating Egress Connectivity Verification State
If an Connectivity Verification Session object is received which
matches the Source_IP_Addr and FEC Stack of existing CV state but has
a different Discriminator, new state is created as normal with two
exceptions. First the new state does not create a new timer; instead
Swallow & Nadeau Standards Track [Page 7]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006
the state points to the timer of the existing state. Second, once an
MPLS Connectivity Verification Probe has been received containing the
new Discriminator, the old state MAY be removed.
If either the Min_TX_Interval or Detection_Multiplier has changed,
the Detection_Time is recalculated.
If the Administratively_Down flag transitions from down to up, then
the Detection_Timer is set to Detection_Time and stated.
If the Administratively_Down flag transitions from up to down, then
the Detection_Timer is stopped.
If the Forward_Defect flag changes state, an up call to any regis-
tered applications is made.
4. MPLS Connectivity Verification Probing
A new LSP Ping message, the MPLS Connectivity Verification Probe, is
defined for connection verification probing. MPLS Connectivity Veri-
fication Probes are sent by the root node of the tree. Leaves listen
for these messages and alarm in their absence.
4.1. MPLS Connectivity Verification Probe
The definitions of the Version Number and Message Type fields are as
in [LSP-PING]. The message type is 5 (provisional; to be assigned by
IANA). The Discriminator is the value that was advertised in the
associated Connectivity Verification Session object.
The message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | MUST Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | MUST Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Swallow & Nadeau Standards Track [Page 8]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006
4.2. Sending MPLS Connectivity Verification Probes
The root forms an MPLS Connectivity Verification Probes formated as
above with the Discriminator set to a value associated with the LSP
to be probed. The message encapsulated in UDP. The source UDP port
is chosen by the sender; the destination UDP port is set to <tba>.
The source IP address is set to the address used in the MPLS Echo
Request Message used to bootstrap this session. The destination
address is set to any address in the range 127.x.x.x. The IP TTL is
set to 1. he packet is transmitted periodically on the LSP. The
packets MAY be jittered, but MUST be sent within Min_CV_TX_Interval
microseconds of the previous message.
4.3. Receiving MPLS Connectivity Verification Probes
Receivers listen for these messages based on the state received in
the CV Session objects. When a message arrives the receiver checks
to see if it has state for the tuple <Source_IP_Addr, Discriminator>.
If so it resets the associated CV_Detection_Timer to Detection_Time
microseconds. Note that during a change in Discriminators, more than
one <Source_IP_Addr, Discriminator> may be pointing to a particular
timer (with the Source_IP_Addr constant). In this situation there
are also multiple Detection_Intervals which could have differing val-
ues. The Detection_Timer MUST be updated with the value associated
with the received Discriminator.
4.4. MPLS Connectivity Verification UDP Port
MPLS Connectivity Verification Probes MUST be sent to port <to be
assigned by IANA>.
5. Multicast LDP FEC Stack Sub-object
The format of the Multicast LDP FEC Stack sub-object is shown below.
The Sub-TLV type is <tba> (to be assigned by IANA).
Swallow & Nadeau Standards Track [Page 9]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address Length| Root Node Addr|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Node Address (Cont.) |
~ " ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family
A two octet quantity containing a value from ADDRESS FAMILY
NUMBERS in [3] that encodes the address family for the Root LSR
Address.
Address Length
The length of the Root LSR Address in octets.
Root Node Address
A host address encoded according to the Address Family field.
Opaque Length
The length of the Opaque Value, in octets.
Opaque Value
An opaque value elements which uniquely identifies the P2MP LSP
in the context of the Root Node.
If the Address Family is IPv4, the Address Length MUST be 4; if the
Address Family is IPv6, the Address Length MUST be 16. No other
Address Lengths are defined at present.
Swallow & Nadeau Standards Track [Page 10]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006
6. Security Considerations
TBD
7. IANA Considerations
This document makes the following codepoint assignments (pending IANA
action):
Registry Codepoint Purpose
UDP Port tba MPLS Verification Request
LSP Ping Message Type 5 MPLS Connectivity Verification
Probe
LSP Ping Object Type 13 Connectivity Verification
Parameters
LSP Ping FEC Stack tba Multicast LDP FEC
Sub-object Type
8. Acknowledgments
The authors would like to thank Vanson Lim for his comments and sug-
gestions.
9. References
9.1. Normative References
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[SELF-TST] Swallow, G. et al., "Label Switching Router Self-Test",
<draft-ietf-mpls-lsr-self-test-07.txt>, June 2006.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Swallow & Nadeau Standards Track [Page 11]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006
[MCSTPING] "Detecting Data Plane Failures in Point-to-Multipoint
MPLS Traffic Engineering - Extensions to LSP Ping",
<draft-ietf-mpls-p2mp-lsp-ping-01.txt>, April 2006.
9.2. Informative References
[MPLS-BFD] Aggarwal, R., et al., "
10. Authors' Addresses
George Swallow
Cisco Systems, Inc.
1414 Massachusetts Ave
Boxborough, MA 01719
Email: swallow@cisco.com
Tom Nadeau
Cisco Systems, Inc.
1414 Massachusetts Ave
Boxborough, MA 01719
Email: tnadeau@cisco.com
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
December 2006
Swallow & Nadeau Standards Track [Page 12]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 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.
Issues:
Named Leaves Only
To set up CV monitoring to a subset of leaves
Error Suppression
Is this useful. A leaf with no ability won't recognize the flag.
Can get around this with the do not reply setting.
Sequence Numbers in probes
Explicit withdrawal of a Discriminator
Swallow & Nadeau Standards Track [Page 13]
Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006
New Receivers Only (N)
This flag indicates that only those receivers which are
establishing new state based on the receipt of this message
SHOULD respond.
Refresh messages MAY be sent with the "New Receivers Only" flag set
to suppress response messages from receivers that have previously
responded. This flag SHOULD only be set when no parameters have been
altered.
Error for same IP, Discriminator & different FEC - or just discard.
F Flag in Probe. Control, or both?
Swallow & Nadeau Standards Track [Page 14]
_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
| |
|