One document matched: draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt
Differences from draft-papadimitriou-ccamp-gmpls-l2sc-lsp-01.txt
CCAMP Working Group D. Papadimitriou (Alcatel)
Internet Draft D. Brungard (ATT)
Expiration Date: December 2004 M. Vigoureux (Alcatel)
A. Ayyangar (Juniper)
June 2004
Generalized MPLS (GMPLS) RSVP-TE Signaling
in support of Layer-2 Label Switched Paths (L2 LSP)
draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt
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
Most efforts on Generalized MPLS (GMPLS) have been focused on
environments covering Circuit oriented LSPs (Sonet/SDH, OTH, etc.).
There is minimal documentation on GMPLS support of Layer-2 Label
Switched Paths (L2 LSPs), e.g. native Ethernet LSPs, Asynchronous
Transfer Mode (ATM) LSPs and Frame Relay (FR) LSPs.
This document details GMPLS capabilities for supporting L2 LSPs in
several network environments including overlays. As such, it
provides a reference detailing the applicability of GMPLS for Layer-
2 switching environments in support of various deployment scenarios,
including the integrated (e.g. multi LSP-region networks), the
augmented/peer and the overlay model (e.g. Generalized VPN (GVPN)
and user-network interfaces (GMPLS UNI)).
D.Papadimitriou et al. - Expires December 2004 1
draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004
1. 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.
In addition the reader is assumed to be familiar with the terms and
concepts developed in [GMPLS-ARCH], [RFC3471], [RFC3473], [RFC3477],
and [GMPLS-UNI], [GMPLS-ENNI] as well as [HIER] and [BUNDLE].
The following abbreviations are used in this document:
CN: Core node
DLCI: Data Link Connection Identifier
EN: Edge node
ICN: Ingress core node
ECN: Egress core node
FA: Forwarding Adjacency
FR: Frame Relay
FSC: Fiber-Switch Capable
HOVC: Higher order virtual container
ISC: Interface Switching Capability
L2-LSP: Layer-2 Label Switched Path
L2SC: Layer-2 Switch Capable
LOVC: Lower order virtual container
LSC: Lambda Switch Capable
PSC: Packet Switch Capable
OTH: Optical transport hierarchy
SDH: Synchronous digital hierarchy.
SONET: Synchronous Optical Network.
TDM: Time-Division Multiplex
VCI: Virtual Channel Identifier
VPI: Virtual Path Identifier
2. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to
support four new classes of interfaces Layer-2 Switch Capable
(L2SC), Time-Division Multiplex (TDM), Lambda Switch Capable (LSC)
and Fiber-Switch Capable (FSC) in addition to Packet Switch Capable
(PSC) already supported by MPLS. All these interface classes have
been considered in [GMPLS-ARCH], [GMPLS-RTG] and [RFC3471].
However, most of the efforts have been concentrated in facilitating
the realization of seamless control integration of IP/MPLS networks
with SONET/SDH (see [T1.105]/[G.707]) or OTH (see [G.709]) transport
networks. The integration of packet and circuit switching
technologies under a unified GMPLS control plane provides an
homogeneous control management approach for both provisioning
resources and recovery techniques (including protection and re-
routing).
D.Papadimitriou et al. - Expires December 2004 2
draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004
While being introduced in [GMPLS-ARCH], [GMPLS-RTG] and [RFC3471],
the GMPLS capability to control L2SC TE links and L2 LSPs has
received very little attention. [RFC3471] defines the Ethernet
encoding types (i.e. the encoding of the LSP being requested) and
Layer-2 as switching capability (i.e. the type of switching to be
performed on a particular link). In this document, a L2 LSP is
defined as a LSP being established between intermediate L2SC
interfaces. These interfaces are defined as being capable of
recognizing frame/cell boundaries and can switch data based on the
content of the frame/cell header (example: interfaces on Ethernet
switches that switch data based on the content of the MAC header).
The motivation for considering GMPLS control of L2 LSPs can be
summarized as follows:
- it automates the provisioning of transparent LAN services. Today,
the delivery of such services can not be automated due to the
control plane/topology driven nature of GMPLS that precludes the
automated triggering of the server layer LSP from an incoming data
flow.
- it facilitates the transport of Ethernet flows without introducing
additional intermediate packet layer LSPs that require themselves
manual provisioning actions.
- it delivers control plane driven recovery capabilities for
a range of technologies (e.g. Ethernet) making classically usage
of mechanisms adapted only for environments where these data plane
technologies had been initially introduced. For instance, Ethernet
Spanning Tree Protocol is less suitable in meshed environments
where control plane driven fast recovery is required and available
- it simplifies the carrier network operations by avoiding dedicated
control protocols for managing Ethernet environments that are not
adapted for large scale environments and for which an IP-based
protocol counter-part exists (e.g. OSPF).
- the use of an IP based addressing scheme elevates the scaling
issues generated by the non-hierarchical MAC addressing scheme.
This capability allows constructing large scale networks taking
advantage of the IP addressing properties.
- it delivers an homogeneous set of signaling mechanisms for
controlling L2 technologies for which integration in common
infrastructure is made difficult due to their particularities
(e.g. ATM and FR).
3. Context
The reference network considered (but not restricted to) in this
document is provided in [GMPLS-UNI], [GMPLS-ENNI] and [RFC3473].
3.1 GMPLS UNI
This network is constituted by a core network including core-nodes
(CN) surrounded by edge nodes (EN) that form the overlay networks.
In addition, the present document assumes the Traffic Engineering
(TE) links inter-connecting the edge and the core nodes are of type
D.Papadimitriou et al. - Expires December 2004 3
draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004
[X,L2SC], where X is any ISC whose switched payload can be carried
over L2SC TE links.
Within the network, the links interconnecting the core nodes can be
either [L2SC,L2SC] or any other technology that can carry Layer-2
Ethernet payload, in particular [TDM,TDM] and [LSC,LSC]. Note also
that in the first case, the EN-CN interface defines an LSP region
boundary (see [HIER]). In the second case, this boundary may be
found within the network.
As defined in [HIER], a (data plane) switching layer is mapped to a
(control plane) LSP region. Following this approach, TE links have
been extended to non adjacent nodes by the introduction of
Forwarding Adjacency (FA). Using this concept, a node may (under the
control of its local policy configuration) advertise an LSP as a TE
link into the same IGP routing instance as the one that induces this
LSP. Such a link is referred to as a Forwarding Adjacency (FA) and
the corresponding LSP to a Forwarding Adjacency LSP (FA-LSP). Since
the advertised entity appears as a TE link, both end-point nodes of
the FA-LSP must belong to the same OSPF area/IS-IS level.
Afterwards, OSPF/IS-IS floods the link-state information about FAs
just as it floods the information about any other TE link. This
allows other nodes to use FAs as any other TE links for path
computation purposes.
3.2 GMPLS E-NNI
When two core networks (1 and 2) are interconnected by two core
nodes (CN1 and CN2), they define an external network-network
interface, as illustrated by the following (simplified) topology:
B---C F---G
/ \ / \
--A 1 CN1---CN2 2 H--
\ / \ /
E---D J---I
In this topology, [A,B], [A,E] and their network 2 counter part are
[L2SC,Y] TE links. Then, the first possibility is that [C,CN1],
[D,CN1] TE links and their network 2 counter part are [Y,L2SC] TE
Links, and [CN1,CN2] is a [L2SC,L2SC] TE link. Therefore, the L2 LSP
that can be setup between node A (ingress) and node H (egress) may
be constituted by two FA LSPs (the first between A and CN1 and the
second between CN2 and H) interconnected by the [L2SC,L2SC] TE link
defined at the E-NNI.
The other possibility is that the [CN1,CN2] TE link is not a
[L2SC,L2SC] TE link. For example, this could be a multi-AS transport
scenario where [CN1,CN2] TE link cannot terminate the L2 LSP. In
this case, CN1 and CN2 would only be transporting the L2 LSP from A
to H on top of some other LSP. So, the TE link between [CN1,CN2]
would then have to be [Y,Y] in which case there would be a single
FA-LSP from A to H.
D.Papadimitriou et al. - Expires December 2004 4
draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004
Applicability of GMPLS RSVP-TE signaling [RFC-3473] at the E-NNI is
detailed in [GMPLS-ENNI].
3.3 GMPLS Signaling Channel
For nodes inter-connected by point-to-point native L2 interfaces,
the signaling channel may be out-of-band or in-band. In the latter
case, several implementation choices are possible for the GMPLS
signaling channel: 1) specific Ethertype that allows discrimination
between data and control traffic (that may be directed towards a
dedicated destination MAC address), 2) dedicated VLAN ID, VPI/VCI
(see [RFC3035], Section 7) or DLCI (see [RFC3034], Section 6) for
the control traffic, and 3) use of a dedicated destination MAC
address for reaching the peering GMPLS controller. Nevertheless, the
signaling transport implementation MUST be strictly independent of
the signaling transport mechanism used between peering GMPLS nodes.
4. Addressing
Addressing follows the rules defined in [GMPLS-UNI] and [GMPLS-
ENNI]. The SESSION and SENDER_TEMPLATE/FILTER_SPEC objects are end-
to-end significant i.e. a single end-to-end RSVP session is defined
(in compliance with the RSVP paradigm).
5. Signaling
L2 LSP setup, notification, graceful and non-graceful deletion
procedures follow [RFC3471], [RFC3473], [GMPLS-UNI] and [GMPLS-
ENNI]. Signaling mechanisms applies to both uni- and bi-directional
L2 LSP.
Translation of the L2 LSP request at the edge CN can make use of one
of the following method: 1) direct end-to-end LSP [RFC3473], 2) LSP
splicing [RFC3473] and stitching, 3) LSP nesting into a FA-LSP
[HIER]. Note that techniques for automated LSP stitching are
described in [MPLS-IRN].
Also, in the overlay context, L2 LSPs nesting into a FA-LSP can be
used when the ingress/egress edge CN provides (flow) multiplexing
capabilities.
5.1 L2 Generalized Label Request
The Generalized Label Request is defined in [RFC3471], Section 3.1.
The different LSP Encoding Type and Switching Type (of the
GENERALIZED_LABEL REQUEST object) that can be used for requesting L2
LSP label is detailed in Table 1.
Value LSP Encoding type Value Switching Type
----- ----------------- ----- --------
2 Ethernet 51 L2SC
14 (new) ATM 51 L2SC
D.Papadimitriou et al. - Expires December 2004 5
draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004
15 (new) Frame-Relay 51 L2SC
Table 1: LSP Encoding Type and Switching Type code-points
for Ethernet, ATM and FR LSPs
For the Generalized PID (G-PID) that identifies the payload carried
by an LSP, standard Ethertype values are used for Ethernet LSPs.
5.2 L2 SENDER_TSPEC and FLOWSPEC
New L2 SENDER_TSPEC and FLOWSPEC objects are introduced to describe
bandwidth and delay/jitter characteristics for the L2 LSP as well as
any such L2 traffic specific characteristics.
As per [RFC3471], GMPLS allows the inclusion of technology specific
parameters in signaling. The intent is for all technology specific
parameters to be carried, when using RSVP-TE, in the SENDER_TSPEC
and other related objects. So new L2 SENDER_TSPEC and FLOWSPEC
objects are defined as follows. These traffic parameters MUST be
used when L2SC is specified in the LSP Switching Type field of a
Generalized Label Request (see [RFC3471]) and the LSP encoding type
is Ethernet, ATM or Frame-Relay. The TLVs in the traffic parameters
are optional.
5.2.1 L2 SENDER_TSPEC object
The L2 SENDER_SPEC object (Class-Num = 12, Class-Type = 6) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (12)| C-Type (6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Granularity | MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Switching Granularity (SG): 16 bits
This field indicates the type of L2 link that comprises the
requested LSP.
The permitted L2 Link Type values:
Value Switching Granularity
----- ------------------------
1 Ethernet Port
2 Ethernet VLAN
3 ATM Port
D.Papadimitriou et al. - Expires December 2004 6
draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004
4 ATM VP Bundle
5 ATM VP
6 ATM VC
7 Frame Relay Port
8 Frame Relay DLCI
Value 0 is reserved. Values 128 through 255 are reserved for
vendor specific usage.
MTU: 16 bits
This is a two-octet value indicating the MTU in octets
TLV:
The L2 SENDER_TSPEC object MUST include at least one and MAY
include more than one TLV. Each TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 16 bits
Indicates the total length of the TLV, i.e., 4 + the length of
the value field in octets. A value field whose length is not
a multiple of four MUST be zero-padded so that the TLV is
four-octet aligned.
Type: 16 bits
Indicates QoS type of the traffic. Defined values are:
Type Length Format Description
--------------------------------------------------
1 20 See below L2_QoS
Types 128 through 255 are reserved for vendor specific TLVs.
Type 1 TLV (L2 QoS) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Class | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth (32-bit IEEE floating point number) |
D.Papadimitriou et al. - Expires December 2004 7
draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jitter (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Traffic Class: 8 bits
Identifies the traffic class, default value is 0x0001. Value
0x0000 is reserved.
Reserved: 24 bits
These bits SHOULD be set to zero when sent and MUST be ignored
when received.
Bandwidth: 32 bits
The requested bandwidth for the L2 LSP. The unit is bytes per
second. For instance, a 1Gbps Ethernet LSP will have a value
of 0x4CEE6B28.
Jitter: 32 bits
Indicates the maximum acceptable jitter (in microseconds) for
this LSP. If unspecified, this value is set to 0x00000000.
Delay: 32 bits
Indicates the maximum acceptable delay (in microseconds) for
this LSP. If unspecified, this value is set to 0x00000000.
5.2.2 L2 FLOWSPEC object
The L2 FLOWSPEC object (Class-Num = 12, Class-Type = 6) has the same
format as the L2 SENDER_TSPEC object.
5.2.3 Processing
The L2 SENDER_TSPEC object carries the traffic specification
generated by RSVP session sender. The L2 SENDER_TSPEC object SHOULD
be forwarded unchanged and delivered to both intermediate and egress
nodes and MAY be updated on a per-hop basis by adding or removing
TLVs. The L2 FLOWSPEC object carries reservation request information
generated by receivers. As any FLOWSPEC object, the information
content of the L2 FLOWSPEC object flows upstream towards ingress
node.
For a particular sender in a RSVP session the contents of the
FLOWSPEC object received in a Resv message SHOULD be identical to
the contents of the SENDER_TSPEC object sent in the corresponding
Path message. If the objects do not match, a ResvErr message with a
D.Papadimitriou et al. - Expires December 2004 8
draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004
"Traffic Control Error/Bad Flowspec value" error SHOULD be
generated.
Intermediate and egress nodes MUST verify that the node itself and
the interfaces on which the LSP will be established can support the
requested Switching Granularity, MTU and values included in sub-
object TLVs. For instance, intermediate and egress nodes processing
MUST ensure they do not reach the delay or the jitter maximum
acceptable value as indicated in the corresponding TLV. If the
requested value(s) can not be supported, the receiver node MUST
generate a PathErr message with a "Traffic Control Error/Service
unsupported" indication (see [RFC2205]).
In addition, if the MTU field is received with a value smaller than
the minimum transfer unit size of the L2 specific technology (e.g.
46 bytes for Ethernet, 38 bytes for IEEE 802.3), the node MUST
generate a PathErr message with a "Traffic Control Error/ Bad Tspec
value" indication (see [RFC2205]).
There is no Adspec associated with the L2 SENDER_TSPEC. Either the
Adspec is omitted or an Int-serv Adspec with the Default General
Characterization Parameters and Guaranteed Service fragment is used,
see [RFC2210].
5.3 L2 Label
L2 LABEL object follows the generic rules of the GENERALIZED_LABEL
object (Class-Num = 16) defined in [RFC3471] for the C-Type 2. This
is a 32-bit label value that allows the sending and receiving node
performing the link local operations for the requested L2 LSP.
The interpretation of the received label depends on the type of the
link over which the label is used. The received label MUST be
interpreted according the requestor traffic parameters, i.e. a label
by itself does not allow knowing the detailed properties of the L2
LSP being requested (i.e. L2 labels are context sensitive).
Table 2 summarizes the L2 labels representation (that can be
supported over [X,L2SC], [L2SC,L2SC] and [L2SC,X] TE links) and
assigned upon reception of the LSP Encoding and Switching Types:
LSP Encoding type Switching Type Label
----------------- -------------- -----------------------------
Ethernet L2SC Port, VLAN ID
ATM L2SC Port, VPI, VCI, VP Bundle ID
Frame-Relay L2SC Port, DLCI
Table 2. L2 Labels
Ethernet Port, ATM Port and Frame Relay Port labels are encoded
right justified aligned in 32 bits (4 octets). Ethernet VLAN ID
labels are encoded with the VLAN ID value (12 bits) right justified
in bits 20-31 (and preceding bits must be set to 0). ATM VPI/VCI
D.Papadimitriou et al. - Expires December 2004 9
draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004
labels are encoded per [RFC3036] Section 3.4.2.2. Frame-Relay DLCI
label values are encoded per [RFC3036] Section 3.4.2.3.
Bi-directional L2 LSPs are indicated by the presence of an upstream
label in the Path message. Upstream label assignment follows the
format of the UPSTREAM LABEL object and the procedures defined in
[RFC3473].
5.4 Interface Identification
Interface identification follows the rules defined in [RFC3473],
Section 8.1 and [RFC3477].
6. Explicit Routing
6.1 EXPLICIT_ROUTE Object (ERO) Processing
EXPLICIT ROUTE objects can make use of the subobjects defined in
[RFC3209] for numbered interfaces and TE links, [RFC3477] for
unnumbered interfaces and TE links and finally [RFC3473] for labels.
EXPLICIT ROUTE objects processing MUST follow the procedures defined
in [RFC3209], [RFC3473], [RFC3477], and [GMPLS-UNI] and [GMPLS-ENNI]
when applicable.
6.2 RECORD_ROUTE Object (RRO) Processing
RECORD ROUTE objects can make use of the subobjects defined in
[RFC3209] for numbered interfaces, TE links and labels, [RFC3477]
for unnumbered interfaces and TE links. RECORD ROUTE objects
processing MUST follow the procedures defined in [RFC3209],
[RFC3473], [RFC3477], and [GMPLS-UNI], [GMPLS-ENNI] when applicable.
6.3 Explicit Label Control
Explicit label control refers to the label identification of the
egress TE link. An ingress node may include an ERO for which the
last hop includes the node_ID of the egress node and any other sub-
objects necessary to uniquely identify the TE link, component link
and labels for the requested Ethernet LSP.
Note: in the overlay context, when the L-bit is set, this last-hop
may be the only hop included in the ERO (see [GMPLS-UNI]).
7. Security considerations
In its current version, this memo does not introduce new security
consideration from the ones already detailed in [RFC3471] and
[RFC3473].
8. IANA Considerations
Two values have to be defined by IANA for this document.
D.Papadimitriou et al. - Expires December 2004 10
draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004
Two RSVP C-Types in registry:
http://www.iana.org/assignments/rsvp-parameters
- L2 SENDER_TSPEC object: Class = 12, C-Type = 6 (Suggested value)
- L2 FLOWSPEC object: Class = 9, C-Type = 6 (Suggested value)
IANA is also requested to track the code-point spaces extended
and/or updated by this document. That is:
- LSP Encoding Type
- Generalized PID (G-PID)
9. Acknowledgments
The authors would like to acknowledge Emmanuel Dotaro for the
fruitful discussions and Mastuura Nobuaki for his useful comments to
this document.
10. References
10.1 Normative References
[BUNDLE] K.Kompella et al., "Link Bundling in MPLS Traffic
Engineering", Internet Draft, Work in Progress, draft-
ietf-mpls-bundle-04.txt, July 2002.
[GMPLS-ARCH]E.Mannie (Editor) et al., "Generalized Multi-Protocol
Label Switching (GMPLS) Architecture", Internet Draft,
Work in Progress, draft-ietf-ccamp-gmpls-architecture-
07.txt, May 2003.
[GMPLS-UNI] G.Swallow et al., "GMPLS UNI: RSVP Support for the
Overlay Model", Internet Draft, Work in Progress, draft-
ietf-ccamp-gmpls-overlay-04.txt, April 2004.
[GMPLS-RTG] K.Kompella and Y.Rekhter (Editors) et al., "Routing
Extensions in Support of Generalized MPLS", Internet
Draft, Work in Progress, draft-ietf-ccamp-gmpls-routing-
09.txt, October 2003.
[HIER] K.Kompella and Y.Rekhter, "LSP Hierarchy with
Generalized MPLS TE", Internet Draft, Work in Progress,
draft-ietf-mpls-lsp-hierarchy-08.txt, September 2002.
[RFC2205] R.Braden (Editor) et al., "Resource ReserVation
Protocol -- Version 1 Functional Specification", RFC
2205, September 1997.
[RFC2210] J.Wroclawski, "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2961] L.Berger et al., "RSVP Refresh Overhead Reduction
D.Papadimitriou et al. - Expires December 2004 11
draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004
Extensions", RFC 2961, April 2001.
[RFC3034] A.Conta et al., "Use of Label Switching on Frame Relay
Networks Specification", RFC 3034, January 2001.
[RFC3035] B.Davie et al., "MPLS using LDP and ATM VC Switching",
RFC 3035, January 2001.
[RFC3036] L.Andersson et al., "LDP Specification", RFC 3036,
January 2001.
[RFC3209] D.Awduche et al., "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC3471] L.Berger (Editor) et al., "Generalized Multi-Protocol
Label Switching (GMPLS) - Signaling Functional
Description", RFC 3471, January 2003.
[RFC3473] L.Berger (Editor) et al., "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC3477] K.Kompella and Y.Rekhter, "Signalling Unnumbered
Links in Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
[RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
10.2 Informative References
[MPLS-IRN] A.Ayyangar et al., "Inter-region MPLS Traffic
Engineering", Internet Draft, Work in progress, draft-
ayyangar-inter-region-te-01.txt, October 2003.
11. Author's addresses
Dimitri Papadimitriou (Alcatel)
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium
Phone : +32 3 240 8491
EMail: dimitri.papadimitriou@alcatel.be
Deborah Brungard (AT&T)
Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA
Phone: +1 732 420 1573
EMail: dbrungard@att.com
D.Papadimitriou et al. - Expires December 2004 12
draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004
Martin Vigoureux (Alcatel)
Route de Nozay,
91461 Marcoussis cedex, France
Phone: +33 1 6963 1852
EMail: martin.vigoureux@alcatel.fr
Arthi Ayyangar (Juniper)
1194 N.Mathilda Ave
Sunnyvale, CA 94089, USA
EMail: arthi@juniper.net
12. Intellectual Property Notice
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.
12.1 IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with RFC 3668.
D.Papadimitriou et al. - Expires December 2004 13
draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004
12. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
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.
D.Papadimitriou et al. - Expires December 2004 14| PAFTECH AB 2003-2026 | 2026-04-23 21:23:34 |