Internet DRAFT - draft-cai-ppvpn-vc-rsvp-te
draft-cai-ppvpn-vc-rsvp-te
Internet Draft November, 2001
Document: draft-cai-ppvpn-vc-rsvp-te-00.txt Expires May, 2002
Martin Machacek Lior Shabtay
Ting Cai Marty Borden
Pascal Menezes Atrica, Inc.
Terabeam Networks, Inc.
Signaling Virtual Circuit Label Using RSVP-TE
Status of this Memo
This document is an Internet-Draft and is subject to all provisions of
Section 10 of RFC2026.
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.
Abstract
The virtual circuits for a provider provisioned virtual private network
(PPVPN) using MPLS may be set up in a number of ways. This draft
discusses the use of RSVP-TE as a VC setup mechanism.
Cai, et. al. Page 1 Internet Draft VC-RSVP-TE Nov., 2001
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
1.Introduction.....................................................3
2.Conventions used in this document................................3
3.VC Models........................................................4
4.Motivation.......................................................5
5.Extensions to RSVP-TE............................................6
VC LABEL Object................................................6
VC LABEL REQUEST Object........................................8
Processing Rules..............................................10
6.Scalability.....................................................12
7.Refresh-Reduction Considerations................................13
8.Membership discovery............................................14
9.Security Considerations.........................................14
10. IANA Considerations...........................................14
11. Authors' Addresses............................................14
Acknowledgments...................................................15
References........................................................15
Cai, et. al. Expires April, 2002 Page 2 Internet Draft VC-RSVP-TE Nov., 2001
1. Introduction
A provider-provisioned virtual private network (PPVPN) consists of a
network with virtual circuits managed by the provider for the benefit of
customers. This document describes methods applicable to PPVPNs that use
MPLS as the virtual circuit (VC) mechanism.
In a relatively small or isolated network, the provider may choose to set
up VCs directly on the behalf of the customer. These MPLS VCs will
likely have characteristics such as QoS that are determined by a SLS
(Service Level Specification). We call this the direct-VC method, since
the VCs are directly managed and not part of a more elaborate tunneling
scheme (as below). For direct-VC MPLS PPVPNs, it is naturally of
importance for the VC management to be sensitive to QoS needs.
A second approach that is generally applicable is the tunneled-VC method.
This approach has received attention in a number of drafts; notably,
Martini et. al. proposed in [5] a method of encapsulating L2 PDUs in MPLS
packets. The method uses a stack of two labels: one specifying the LSP
tunnel across the MPLS network and the other identifying the virtual
circuit (VC) to which the L2 PDUs belong. In [5], the tunneled-VC method
distributes VC labels using LDP in downstream-unsolicited mode[2].
For both the direct-VC approach and the tunneled-VC approach we see
advantages to allowing the use RSVP-TE [3] to distribute the VC labels.
This draft proposes a simple extension to RSVP-TE to signal VC labels
using RSVP-TE. The extension includes two new RSVP object classes, VC
LABEL and VC LABEL REQUEST. The data formats, including their
interpretations, are taken from [2] with only minor modifications
required to the RSVP object format. This approach can help simplify
implementations by supporting only one protocol, RSVP-TE, for virtual
circuits and labeled paths.
We will future discuss the motivation for this work below. We then
discuss the data objects and the processing rules. Our discussion
concludes with issues of scalability.
2. 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 [1].
Cai, et. al. Expires April, 2002 Page 3 Internet Draft VC-RSVP-TE Nov., 2001
3. VC Models
In the following text, the objects introduced and operations with them
can be described mostly independent of the location of the endpoints used
for virtual circuits. However, for clarity, it is much easier to refer
to some typical examples when describing the usage than it is to deal
with this abstractly.
The first mode of using VCs we call the direct-VC approach. In this case
the virtual circuit is from end to end, as in the following picture.
Direct-Mode
+------+ +------+ +------+ +------+
| LERa |---| LSR1 |---| LSR2 |---| LERb |
+------+ +------+ +------+ +------+
<---------- VC LSP ---------->
In the tunnel-mode, the virtual circuit is established within an existing
LSP that was likely established for traffic engineering purposes. In
this example, there are 2 stacked labels, a label for the forwarding
adjacency of the TE tunnel and an inner label for the VC.
Tunnel-Mode
+------+ +------+ +------+ +------+
| LERa |---| LSR1 |---| LSR2 |---| LERb |
+------+ +------+ +------+ +------+
<---------- Tunnel LSP ------>
<---------- VC LSP ---------->
A third mode is a hybrid of the two above. Here, a tunnel is established
between LSRs, say for traffic engineering purposes. This tunnel appears
to the LSRs as a direct VC, used for a forwarding adjacency. The VC
tunnel is established end-to-end between LERs; the first LSR in the path
must know to put this VC LSP within a particular tunnel LSP. From the
LER's point of view, the VC tunnel appears as a direct-mode VC. At the
LSR, the VC tunnel appears as a tunnel-mode VC that originated outside of
the LSR.
Cai, et. al. Expires April, 2002 Page 4 Internet Draft VC-RSVP-TE Nov., 2001
Hybrid-Mode
+------+ +------+ +------+ +------+
| LERa |---| LSR1 |---| LSR2 |---| LERb |
+------+ +------+ +------+ +------+
<- Tunnel LSP ->
<---------- VC LSP ---------->
4. Motivation
The main motivation for this draft is to give operators of networks using
exclusively RSVP-TE based signaling the option to use the same protocol
also for signaling of Virtual-Circuits.
This can help to simplify and improve the manageability and
maintainability of the network. For example, the operators of the network
do not need to learn an additional protocol, can use similar management
tools, and do not need to understand the interaction between the two
different signaling protocols running on the same network. Additional
benefits to the operator are possible reduced cost and increased
reliability, as devices in the network need to execute fewer protocols,
which means less resource consumption and fewer potential bugs in each
device.
Using two different signaling protocols concurrently may cause side
effects and interference. For example, consider the case of using LDP for
signaling VCs that are aggregated through an LSP, as in the hybrid-mode.
Here, the VC signaling between the LERs (which may not be directly
connected) may follow a path that is different than the path of the
tunnel LSP. This is due to the fact that the LDP signaling is performed
using TCP, which is usually forwarded in native IP. Native IP does not
necessarily forward the packets in the path of the tunnel LSP that
carries the signaled VCs. This situation could lead to an inconsistent
failure decision, such as when the tunnel LSP fails but the LDP-session
still works or when the LDP-session fails while the tunnel LSP is
operational. It is desirable to consider a solution that avoids problems
of mixed signaling methods.
In addition to overall manageability considerations, there is the
potential for increased functionality in RSVP-TE signaling of the VCs.
RSVP-TE allows association of QoS parameters with specific VCs. This
allows for fine-grained traffic engineering when needed. In some devices
and network designs this can be an advantage.
We give an example of this QoS capability, nicely illustrated by a
hybrid-VC approach. Suppose that the PE devices are low-bandwidth
Cai, et. al. Expires April, 2002 Page 5 Internet Draft VC-RSVP-TE Nov., 2001
devices that serve a small number of VCs. In this case it makes more
sense to perform the aggregation on a larger-bandwidth intermediate LSR.
A possible design is to let each VC be mapped to its own LSP going from
the PE device to the other side through a number of intermediate LSRs,
and have the first intermediate LSR aggregate a number of VCs through a
tunnel ending at the last intermediate LSR. The VCs aggregated in one
tunnel can be originating in different PE-devices attached to that LSR,
as long as they are going in the same direction. This requires signaling
the VCs using RSVP-TE, so that the intermediate LSRs performing the
aggregation would be able to get the QoS and bandwidth-reservation
parameters of the different VCs, as signaled by the PE devices.
An additional advantage provided by RSVP-TE is easier support of fault
tolerance. (See, e.g., [9], [10], [11] for background.) With fault-
tolerance support, LSPs and VCs can survive resets, recovery after
hardware failures, etc. This means fast recovery of service without
needing to signal all LSPs and VCs after the failure. In RSVP-TE the
support for fault tolerance mainly requires the device to maintain the
LSPs and VCs information after the failure. LDP assumes a reliable
transport, and uses TCP for this purpose, which makes it harder to
support fault-tolerance.
We believe that selection of signaling protocol for VCs should be
conscious decision of every network architect based on analysis of
network topology, services offered and other aspects of network design
and should not be limited by lack of available standard solutions.
5. Extensions to RSVP-TE
VC LABEL Object
The VC LABEL object MAY be used in RSVP RESV messages when replying to
RSVP PATH messages with VC LABEL REQUEST object. The VC LABEL object
SHOULD only be interpreted by the originator of the VC LABEL REQUEST
object at the ingress of the tunnel. Multiple VC LABEL objects MAY be
present in one RESV message. If multiple VC LABEL objects with identical
VC ID are present, the first object MUST be used while others MUST be
ignored and notification to management SHOULD be generated.
The VC LABEL Class number is 208 (see sect. 9) and currently only C-Type
1 is defined. The VC LABEL class is optional from RSVP point of view.
Based on rules in Section 3.10 of [4] all label switch routers (LSR) that
do not support this class MUST ignore the object and pass it unchanged.
LSRs supporting the VC Label Request class MUST also support VC Label
class.
The VC LABEL object has the following format:
Cai, et. al. Expires April, 2002 Page 6 Internet Draft VC-RSVP-TE Nov., 2001
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |C| VC Type |VC info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface parameters |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC LABEL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved Field
MUST be set to zero on transmission and ignored on receipt.
VC TYPE
A 15-bit quantity containing a value that represents the type of VC.
Assigned values are:
VC Type Description
0x0001 Frame Relay DLCI
0x0002 ATM AAL5 VCC transport
0x0003 ATM transparent cell transport
0x0004 Ethernet VLAN
0x0005 Ethernet
0x0006 HDLC ( Cisco )
0x0007 PPP
0x8008 CEM [8]
0x0009 ATM VCC cell transport
0x000A ATM VPC cell transport
0x000B MPLS
Control word bit (C)
The C bit is used to signal whether control word (as defined in [5])
will be used for the VC.
C bit = 1 control word present on this VC.
C bit = 0 no control word present on this VC.
VC information length
Length of the VC ID field and the interface parameters field in octets.
If this value is 0, then it references all VCs using the specified group
Cai, et. al. Expires April, 2002 Page 7 Internet Draft VC-RSVP-TE Nov., 2001
ID and there is no VC ID present, nor any interface parameters. The
length must be multiple of 4.
Group ID
An arbitrary 32 bit value which represents a group of VCs that is used to
augment the VC space. This value MUST be user configurable. The group ID
is intended to be used as a port index, or a virtual tunnel index. To
simplify configuration a particular VC ID at ingress could be part of the
virtual tunnel for transport to the egress router. The Group ID can be
used to send a wild card label withdrawals to remote LSRs upon physical
port failure.
VC ID
A non-zero 32-bit connection ID that together with the VC type,
identifying VC for which label is being provided.
Interface parameters
A variable length field that is used to provide interface specific
parameters of the egress interface of the VC. Format of this field is
described in section 5.1 of [2]. Interface parameter field MAY be present
even if no special parameters were requested in the corresponding LABEL
REQUEST object. Total length of this field MUST be multiple of 4 and if
necessary it MUST be padded with zeroes to the nearest 32-bit boundary.
VC LABEL
Generic MPLS label encoded right aligned in 4 octets. Note that ATM and
Frame Relay labels cannot be used in this context.
VC LABEL REQUEST Object
The VC LABEL REQUEST object MAY be used in RSVP PATH messages to request
label mapping for a particular VC from the egress LSR. The VC LABEL
REQUEST object SHOULD be interpreted only by the egress LSR whose router
ID is the tunnel end point IP address in the Session object of the RSVP
PATH message. (This requirement is of interest primarily for the direct-
VC method.) Multiple VC LABEL REQUEST objects MAY be present in one PATH
message. If multiple LABEL REQUEST objects with identical VC ID are
present only the first one MUST be used while others MUST be ignored and
notification to management SHOULD be generated.
The VC LABEL REQUEST class number is 209 (see sect. 9) and currently only
C-Type 1 is defined. The VC LABEL REQUEST object is optional from RSVP
point of view. Based on rules in Section 3.10 of [4] all LSRs that do
not support this class MUST ignore it and pass it unchanged. LSRs
supporting VC LABEL REQUEST class MUST also support VC LABEL class.
Cai, et. al. Expires April, 2002 Page 8 Internet Draft VC-RSVP-TE Nov., 2001
The VC LABEL REQUEST object has 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |C| VC TYPE |VC Info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Parameters |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved Field
MUST be zeroed on transmission and ignored on receipt.
VC TYPE
A 15-bit quantity containing a value which represents the type of VC.
Assigned Values are:
VC Type Description
0x0001 Frame Relay DLCI
0x0002 ATM AAL5 VCC transport
0x0003 ATM transparent cell transport
0x0004 Ethernet VLAN
0x0005 Ethernet
0x0006 HDLC ( Cisco )
0x0007 PPP
0x8008 CEM [8]
0x0009 ATM VCC cell transport
0x000A ATM VPC cell transport
0x000B MPLS
Control word bit (C)
The C bit is used to signal whether control word (as defined in [5]) will
be used for the VC.
C bit = 1 control word present on this VC.
C bit = 0 no control word present on this VC.
VC information length
Length of the VC ID field and the interface parameters field in octets.
If this value is 0, then it references all VCs using the specified group
Cai, et. al. Expires April, 2002 Page 9 Internet Draft VC-RSVP-TE Nov., 2001
ID and there is no VC ID present, nor any interface parameters. The
length must be multiple of 4.
Group ID
An arbitrary 32 bit value which represents a group of VCs that is used to
augment the VC space. This value MUST be user configurable. The group ID
is intended to be used as a port index, or a virtual tunnel index. To
simplify configuration a particular VC ID at ingress could be part of the
virtual tunnel for transport to the egress router. The Group ID is very
useful to send a wild card label withdrawals to remote LSRs upon physical
port failure.
VC ID
A non-zero 32-bit connection ID that together with the VC type,
identifying VC for which label is being provided.
Interface parameters
Variable length field is used to provide interface specific parameters of
the ingress interface of the VC. Format of this field is described in
section 5.1 of [2]. Interface parameter field MAY be present even if no
special parameters were requested in corresponding LABEL REQUEST object.
Total length of this field MUST be multiple of 4 and if necessary it MUST
be padded with zeroes to the nearest 32-bit boundary.
Processing Rules
Ingress
To request VC label for a particular virtual circuit, the ingress of L2
tunnel places VC LABEL REQUEST objects with appropriate VC Type in RSVP
PATH messages and sends them to the egress. VC Label Request objects
SHOULD be placed immediately after LABEL REQUEST objects in the PATH
message. The ingress node SHOULD set the C bit in the VC LABEL REQUEST
object if it intends to use the control word in the encapsulation of L2
PDUs. The ingress node MUST NOT send data over the L2 circuit if:
- The egress node does not reply with a VC LABEL object,
- The VC LABEL object has C bit set and the LSR is not capable of
supporting control word in the encapsulation,
- Interface parameters specified in the VC LABEL object are not
acceptable, or
- Interface parameters specified in VC LABEL REQUEST object are not found
in the corresponding VC LABEL object.
The ingress node SHOULD stop sending VC LABEL REQUEST objects in RSVP
PATH messages if it detects that the egress node of the L2 channel is not
operational.
Cai, et. al. Expires April, 2002 Page 10 Internet Draft VC-RSVP-TE Nov., 2001
If the ingress does not receive RESV replies with VC LABEL objects from
the egress after certain timeout period, it SHOULD use methods
appropriate in the L2 protocol to signal that the receiving side of the
virtual circuit is not operational. The signal SHOULD be sent to the L2
link that is being tunneled over MPLS network.
If the ingress wants to change the VC setup, it simply sends revised VC
LABEL REQUEST objects in PATH messages. The virtual circuit that does
not have the corresponding VC ID in the revised VC LABEL REQUEST object
SHOULD be torn down.
If the ingress wants to tear down a particular virtual circuit it MUST
stop sending VC Label Request object in PATH messages. Alternatively it
MAY also initiate the teardown procedure as defined in [4].
In direct-VC mode the label to be used for the VC is the one received in
the LABEL object. In tunneled-VC mode the label to be used for the
VC is the one received in the VC LABEL object.
Egress
The egress node replies to VC LABEL REQUEST objects in PATH messages with
VC LABEL objects in RESV messages. The egress node MUST NOT reply with VC
LABEL object if:
- The VC Type specified in the VC Label Request is not supported,
- The specified VC ID does not match any configured virtual circuit,
- The VC Label Request object has the C bit set and the egress LSR is not
capable of using control word in L2 PDU encapsulation,
- Interface parameters specified in the VC LABEL REQUEST object are not
acceptable, or,
- The receiving side of the L2 circuit related to the VC ID is not
operational.
The egress node MAY set the C bit to 1 in VC Label object if it requires
the ingress node to use the control word in the encapsulation. This may
occur even if the VC Label Request object that has C bit set to zero. If
interface parameter field is included in the VC LABEL REQUEST, egress LSR
MUST include this field unchanged in the VC LABEL object. It MAY include
interface parameter field in the VC LABEL object even if no such field
was present in the corresponding VC LABEL REQUEST.
If egress does not receive PATH messages with VC LABEL REQUEST objects
after certain timeout period, it SHOULD use methods appropriate for the
L2 protocol to signal that the sending side of the virtual circuit is not
operational. The signal should be sent on the L2 link that is being
tunneled over MPLS network.
If egress wants to change the VC setup, it simply sends revised VC LABEL
objects in RESV messages.
Cai, et. al. Expires April, 2002 Page 11 Internet Draft VC-RSVP-TE Nov., 2001
If egress wants to tear down a particular VC of L2 it MUST stop replying
to the corresponding VC Label Requests. Alternatively it MAY also
initiate the teardown procedure as defined [4].
6. Scalability
The scalability of RSVP-TE greatly improves when implementing the RSVP
refresh-overhead reduction scheme described in [6]. [6] defines
extensions for RSVP that drastically reduce the overhead of the refresh
messages of the protocol, as long as the information delivered in them is
not new. The extensions also improve the overhead and latency of delivery
of new information by the protocol. This improves the scalability of the
RSVP protocol to a level that is similar to that of LDP. Since this draft
adds new objects to be signaled, the refresh reduction scheme should be
enhanced to support unknown objects. See details below.
We have illustrated two possible modes that may be implemented. In the
direct-VC mode, each VC is implemented by an LSP of its own, and in the
tunnel-VC mode, VCs are aggregated into fewer LSPs. The direct-VC mode
one is less scaleable, but is simpler and provides finer control of QoS
of individual VCs. The tunnel-VC mode provides better scalability.
In either mode, or in the hybrid mode, aggregation of VCs into LSPs
should be performed using the technique described in [7]. This draft [7]
suggests using the label-stacking capability of MPLS to allow an LSP to
behave as a single hop for LSPs that flow through it. This enables using
a single LSP to carry a number of VCs flowing between the same two PE
devices. According to [7], signaling of the nested VCs should be
performed by sending the signaling messages nested in the aggregating
LSP. The draft also discusses the issue of sending signaling messages
back, which might be an issue since the LSP is unidirectional and
therefore cannot be used for sending messages in the reverse direction.
The draft states three different options for doing that: using an LSP in
the reverse direction, if exists; unicasting them back to the head-end of
the LSP along the control path; or encapsulate these messages with an
another IP-header with destination-address being the address of the head-
end of the LSP. Please observe that actually, each of these techniques
can be used in the LSP direction as well.
These techniques should be used to ensure that intermediate LSRs do not
take part in the signaling of the VCs, and therefore greatly increase
scalability in terms of memory, processing-power at intermediate nodes,
and reaction-time of the VC creation and deletion and of LSP rerouting.
[7] also discusses forming a forwarding adjacency out of the LSP, by
advertising the LSP as a link into ISIS/OSPF. This is less relevant for
our purposes, although it can be used.
Cai, et. al. Expires April, 2002 Page 12 Internet Draft VC-RSVP-TE Nov., 2001
7. Refresh-Reduction Considerations
RSVP Refresh Overhead Reduction Extensions [6] can be used to reduce the
processing overhead of RSVP refresh messages and improve the scalability
of RSVP. However [6] does not specify how refresh reduction capable nodes
should handle newly defined RSVP objects that are unknown to existing
implementation. While Bundle messages are unaffected by unknown objects,
the implementation needs to compare unknown objects before sending out
Srefresh messages. In a manner of section 3.10 of RSVP [4], the
extension below clarifies the handling of unknown objects and defines
four possible ways that an RSVP Refresh Reduction implementation can
treat an object of unknown class ('b' represents a bit with either 0 or
1):
o Class-Num = 0bbbbbbb
According to [4], the entire RSVP message with this unknown object should
be rejected and an "Unknown Object Class" error should be returned. Thus,
such unknown objects should not be of concern to any Refresh Reduction
implementation.
o Class-Num = 10bbbbbb
The node should ignore the object, and for the purpose of comparison with
previous object, the node should consider it the same and should not send
a trigger message because of this object.
o Class-Num = 110bbbbbb, 1110bbbb
For the purpose of comparison, the node should consider this object as
different from previous objects and send a trigger message instead of a
refresh message. Note in this case, refresh reduction techniques does not
apply and standard RSVP refresh messages have to be used.
o Class-Num = 1111bbbb
The node should include an MESSAGE_ID object in the RSVP message that
propagates this object to the next hop and set the ACK_Desired flag in
the MESSAGE_ID object. When such message is acknowledged by the
MESSAGE_ID_ACK object, the node should delete such objects from its
internal state. This behavior utilizes the reliable delivery mechanism
of RSVP Refresh Reduction RFC and it is especially suitable to end-to-end
objects that intermediate nodes need not to be aware of except delivering
to the end node.
As defined in previous sections, the VC Label Request Object and the VC
Label Object has class number 240 and 241 with leading four bits equal to
1111. With the extension above, the intermediate nodes should delete VC
objects after delivering the objects to the next hop. Thus, these
objects adds very little overhead to the intermediate nodes.
Cai, et. al. Expires April, 2002 Page 13 Internet Draft VC-RSVP-TE Nov., 2001
8. Membership discovery
RSVP-TE works in downstream on-demand mode, making it impossible to
advertise VPN-membership using the signaling protocol. This means that
the VPN-membership data should be delivered by other means.
There are many solutions to this issue. In many networks, membership is
explicitly configured at the edges. Another solution can be to use a
database accessible by the PE devices to centrally hold the VPN-
membership data. A popular scheme is to advertise VPN-membership using
BGP. With the BGP solution, one variation is to advertise the labels
using BGP, in which case signaling of VCs is not required. Another mode
is to advertise only VPN-membership using BGP and still signal the VCs
for label and QoS parameters exchange.
9. Security Considerations
This document does not affect the underlying security issues of MPLS.
This draft does not introduce any security considerations related to
RSVP-TE that are not already part of the existing usage for LSPs.
10. IANA Considerations
The RSVP class number 208 and 209 and their C-Types is pending
IANA approval. This draft requires no further IANA actions.
11. Authors' Addresses
Martin Machacek
Terabeam Networks, Inc.
14833 NE 87th St.
Redmond, WA, USA
Martin.Machacek@Terabeam.com
Ting Cai
Terabeam Networks, Inc.
14833 NE 87th St.
Redmond, WA, USA
(206) 321-6367
Ting.Cai@terabeam.com
Pascal Menezes
Terabeam Networks, Inc.
14833 NE 87th St.
Redmond, WA, USA
(206) 686-2001
Cai, et. al. Expires April, 2002 Page 14 Internet Draft VC-RSVP-TE Nov., 2001
Pascal.Menezes@Terabeam.com
Lior Shabtay
Atrica, Inc.
5 Shenkar St.
Hertzeliya, Israel
Lior_Shabtay@atrica.com
Marty Borden
Atrica, Inc.
30 Shaker Lane
Littleton, MA 01460
mborden@atrica.com
Acknowledgments
We would like to thank Jeff Apple for reviewing the draft and Steve
Cheek and Karel Zikan for their just-in-time help on editing the
draft.
References
1 S. Bradner, BCP 14, RFC 2119, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
2 L. Martini, et. al., "Transport of Layer 2 Frames Over MPLS", draft-
martini-l2circuit-trans-mpls-07.txt, Work in Progress.
3 D. O. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow,
"RSVP-TE: Extensions to RSVP for LSP Tunnels," draft-ietf-mpls-rsvp-
lsp-tunnel-09.txt (To be reissued as a Proposed Standard RFC)
4 R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, RFC 2205,
"Resource Reservation Protocol (RSVP) -- Version 1 Functional
Specification", September, 1997
5 L. Martini, et. al., "Encapsulation Methods for Transport of Layer 2
Frames Over MPLS", draft-martini-l2circuit-encap-mpls-03.txt, Work in
Progress
6 L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasiand, S. Molendini,
RFC 2961, "RSVP Refresh Overhead Reduction Extensions", April 2001.
7 K. Kompella, Y. Rekhter, "LSP Hierarchy with MPLS TE", draft-ietf-
mpls-lsp-hierarchy-02.txt, Work in Progress.
Cai, et. al. Expires April, 2002 Page 15 Internet Draft VC-RSVP-TE Nov., 2001
8 D. O. Awduche, A. Hannan, X. Xiao, "Applicability Statement for
Extensions to RSVP for LSP-Tunnels,"draft-ietf-mpls-rsvp-tunnel-
applicability-02.txt. (To be reissued as an Informational RFC)
9 P. Pan, Y. Rekhter, K. Kompella, F. Liaw, D. Pandarakis, G. Swallow,
J. Drake, "Graceful Restart Mechanism for RSVP-TE", draft-pan-rsvp-
te-restart-01.txt, Work in Progress.
10 A. Farrel, P. Brittain, P. Matthews, E. Gray, "Fault Tolerance for
LDP and CR-LDP", draft-ietf-mpls-ldp-ft-02.txt, Work in Progress.
11 M. Leelanivas, Y. Rekhter, R. Aggarwal, "Graceful Restart Mechanism
for LDP", draft-leelanivas-ldp-restart-01.txt, Work in Progress.
Cai, et. al. Expires April, 2002 Page 16
