Internet DRAFT - draft-cai-vc-rsvp-te
draft-cai-vc-rsvp-te
Internet Draft Martin Machacek
Document: draft-cai-vc-rsvp-te-00.txt Ting Cai
Expires: August 2001 Terabeam Networks, Inc.
February 2001
Signaling Virtual Circuit Label Using RSVP-TE
Status of this Memo
This document is an Internet-Draft and is in full conformance
with 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
This document proposes an extension to RSVP-TE to distribute VC
labels required by L2 circuit over MPLS encapsulation proposed by
Martini et. al. The distribution of VC labels is piggybacked on
signaling of LSP tunnels using two new RSVP objects.
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Conventions used in this document..................................2
VC LABEL Object....................................................2
VC LABEL REQUEST Object............................................4
Processing Rules...................................................6
Security Considerations............................................7
Acknowledgements...................................................8
References.........................................................9
Author's Addresses.................................................9
Cai Internet Draft - Expires August 2001 1
Signaling Virtual Circuit Label Using RSVP-TE February 2001
Introduction
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. Martini et. al.
proposed a method for distributing VC labels using LDP in
downstream-unsolicited mode in [2].
We propose a simple extension to RSVP-TE [3] to signal VC labels
using RSVP-TE in downstream-on-demand mode. 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 by the RSVP object format. This
should simplify implementations supporting both LDP and RSVP-TE.
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].
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 [Note] 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:
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 |
| " |
Cai Internet Draft - Expires August 2001 2
Signaling Virtual Circuit Label Using RSVP-TE February 2001
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC LABEL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
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 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.
Cai Internet Draft - Expires August 2001 3
Signaling Virtual Circuit Label Using RSVP-TE February 2001
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. 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 [Note] 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.
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 |
| " |
Cai Internet Draft - Expires August 2001 4
Signaling Virtual Circuit Label Using RSVP-TE February 2001
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
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 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
Cai Internet Draft - Expires August 2001 5
Signaling Virtual Circuit Label Using RSVP-TE February 2001
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 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,
- interface parameters specified in VC LABEL REQUEST
object was not found in corresponding VC LABEL object.
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.
If 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 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 corresponding VC ID in the revised
VC LABEL REQUEST object SHOULD be torn down.
Cai Internet Draft - Expires August 2001 6
Signaling Virtual Circuit Label Using RSVP-TE February 2001
If ingress wants to tear down a particular virtual circuit it
SHOULD stop sending VC Label Request object in PATH messages.
Alternatively it MAY also initiate the teardown procedure as
defined in [4].
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 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.
- 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.
If egress wants to tear down a particular VC of L2 it SHOULD
stop replying to the corresponding VC Label Requests.
Alternatively it MAY also initiate the teardown procedure as
defined [4].
Security Considerations
This document does not affect the underlying security issues of
MPLS.
Cai Internet Draft - Expires August 2001 7
Signaling Virtual Circuit Label Using RSVP-TE February 2001
Acknowledgements
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.
Cai Internet Draft - Expires August 2001 8
Signaling Virtual Circuit Label Using RSVP-TE February 2001
References
1 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
2 "Transport of Layer 2 Frames Over MPLS", draft-martini-
l2circuit-trans-mpls-04.txt, Work in Progress.
3 "RSVP-TE: Extensions to RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-
lsp-tunnel-07.txt, Work in Progress.
4 RFC 2205 R. Branden, L.Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource Reservation Protococol (RSVP) -- Version 1 Functional
Specification", September, 1997
5 "Encapsulation Methods for Transport of Layer 2 Frames Over
MPLS", draft-martini-l2circuit-encap-mpls-01.txt, Work in Progress
Note: The RSVP class number 208 and 209 and their C-Types is pending
IANA approval.
Author's Addresses
Martin Machacek
Terabeam Networks, Inc.
14833 NE 87th St. Phone:
Redmond, WA, USA Email: Martin.Machacek@Terabeam.com
Ting Cai
Terabeam Networks, Inc.
14833 NE 87th St. Phone: (206) 321-6367
Redmond, WA, USA Email: Ting.Cai@terabeam.com
Cai Internet Draft - Expires August 2001 9
