CCAMP Working Group Kohei Shiomoto (NTT)
Internet Draft Rajiv Papneja (ISOCORE)
Expires: July 2005 Richard Rabbat (Fujitsu)
Category: Best Current Practice
January 2005
Addressing and Messaging in Generalized Multi-Protocol Label
Switching (GMPLS) Networks: Best Practices
draft-shiomoto-ccamp-gmpls-addressing-00.txt
Status of this Memo
By submitting this Internet-Draft, we certify that any applicable
patent or IPR claims of which we are aware have been disclosed, and
any of which we become aware will be disclosed, in accordance with
RFC 3668.
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 describes best practices in addressing and messaging in
Generalized Multi-Protocol Label Switching (GMPLS) networks. The aim
of this document is to facilitate and ensure better interworking of
GMPLS-capable Label Switching Routers (LSR) based on experience
gained in deployments and interoperability testing.
The document recommends best practices for the interpretation and
choice of address and identifier fields within GMPLS protocols and
references specific control plane usage models. It also examines
some common GMPLS Resource Reservation Protocol-Traffic Engineering
(RSVP-TE) signaling message processing issues and recommends best
practices.
Expires July 2005 [Page 1]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
Table of Contents
1. Introduction...................................................3
2. Conventions Used in This Document..............................3
3. Terminology....................................................3
4. Addressing.....................................................4
4.1. OSPF-TE......................................................5
4.1.1. Router Address TLV.........................................5
4.1.2. Link ID sub TLV............................................6
4.1.3. Local Interface IP Address.................................6
4.1.4. Remote Interface IP Address................................6
4.2. ISIS-TE......................................................6
4.3. Use of Addresses in RSVP-TE..................................6
4.3.1. Session Object Destination IPv4 address....................6
4.3.2. Sender Template Object Sender IPv4 address.................6
4.3.3. IF_ID RSVP-TE_HOP Object for Numbered Interfaces...........7
4.3.4. Explicit Route Object (ERO)................................7
4.3.5. Record Route Object (RRO)..................................7
4.4. IP Packet Destination Address................................8
4.5. IP Packet Source Address.....................................8
5. Unnumbered Addressing..........................................8
5.1. OSPF-TE......................................................9
5.1.1. Link Local/Remote Identifiers..............................9
5.2. ISIS-TE......................................................9
5.3. Use of Addresses in RSVP-TE..................................9
5.3.1. IF ID RSVP-TE_HOP Object for Unnumbered Interfaces.........9
5.3.2. Explicit Route Object (ERO)................................9
5.4. Record Route Object (RRO)...................................10
5.5. LSP_Tunnel Interface ID Object..............................10
5.6. IPv6 Addressing.............................................10
6. RSVP-TE Message Content.......................................10
6.1. ERO and RRO Addresses.......................................10
6.1.1. Strict Subobject in ERO...................................10
6.1.2. Loose Subobject in ERO....................................11
6.1.3. RRO.......................................................12
6.2. Forwarding Destination of Path Message with ERO.............13
7. GMPLS Control Plane...........................................13
7.1. Control Channel Separation..................................13
7.2. Native Control Plane........................................13
7.3. Tunneled Control Plane......................................14
7.4. Separation of Control and Data Plane Traffic................15
8. Security Considerations.......................................16
9. Full Copyright Statement......................................16
10. Intellectual Property........................................16
11. Acknowledgement..............................................17
12. Authors' Addresses...........................................17
13. Contributors.................................................17
14. References...................................................18
Expires July 2005 [Page 2]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
1. Introduction
This document describes best practices in addressing and messaging in
networks that use GMPLS [RFC3945] as their control plane. For the
purposes of this document it is assumed that there is a one-to-one
correspondence between control plane and data plane entities. That
is, each data plane switch has a unique control plane presence
responsible for participating in the GMPLS protocols, and that each
such control plane presence is responsible for a single data plane
switch. The combination of control plane and data plane entities is
referred to as a Label Switching Router (LSR). Various more complex
deployment scenarios can be constructed, but these are out of scope
of this document.
The document is organized as follows. Section 3 defines the used
terminology including router ID. Section 4 describes addressing in
OSPF-TE and RSVP-TE. Section 5 describes unnumbered addressing for
these protocols as well. Section 6 describes the RSVP-TE message
content including the choice of outgoing and incoming Interface IDs
for ERO and RRO in the RSVP-TE message, especially for the case of
loose subobject. Section 7 discusses issues related to the GMPLS
control plane with respect to control channel separation and
addressing in the case of native and tunneled control plane.
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 [RFC2119].
3. Terminology
Note that the term 'Router ID' is used in two contexts within GMPLS.
It may refer to an identifier for a participant in a routing
protocol, or it may be an identifier for an LSR that participates in
TE routing. These could be considered as the control plane and data
plane contexts.
In this document, the contexts are distinguished by the following
definitions.
Loopback address - A loopback address is a stable IP address of the
advertising router that is always reachable if there is any IP
Expires July 2005 [Page 3]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
connectivity to it [RFC3630]. Thus a 127/24 address is excluded from
this definition.
TE Router ID - A stable IP address of an LSR that is always reachable
if there is any IP connectivity to the LSR, e.g., a loopback address.
The key attribute is that the address does not become unusable if an
interface on the LSR is down [RFC3477].
Router ID - The OSPF protocol [RFC2328] defines the Router ID to be a
32-bit network unique number assigned to each router running OSPF.
ISIS [RFC1195] includes a similar concept in the SystemID. This
document describes both concepts as the "Router ID" of the router
running the routing protocol. The Router ID is not required to be a
reachable IP address, although it may be set to a reachable IP
address.
Data plane node - A terminal or a device in a computer network that
can be uniquely identified in the network and is capable of
forwarding data.
Control plane node - A terminal or device in a computer network that
can be uniquely identified and does not have data forwarding
capability.
TE node - TBD
TE link - TBD
TE interface - TBD
Control plane node - TBD
4. Addressing
Addresses are assigned to each node and link in both control and data
plane in GMPLS networks. A TE Router ID is defined to identify the
LSR for TE purposes. As used in [RFC3477], the TE Router ID must be
a reachable address in the control plane, and is typically
implemented as a loopback address. It should be advertised by the
routing protocol consistent with normal use of a loopback address, so
that TE Router ID can be reflected in the routing table for the
control plane network. The loopback address is a stable address and
is not assigned to any control or data plane interface so that any
link failure will not cause the node to become unreachable.
The reason why the TE Router ID must be a reachable IP address is
because in GMPLS, control and data plane names /addresses are not
completely separated. An Explicit Route Object (ERO) signaled as a
Expires July 2005 [Page 4]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
part of a Label Switched Path (LSP) setup message contains an LSP
path specified in data plane addresses, namely TE node IDs and TE
link IDs. The message needs to be forwarded as IP/RSVP packet
between LSRs that manage data plane nodes along the path. Hence,
each LSR along the path needs to resolve the next hop data plane
address into the next hop control plane address before the message
could be forwarded to the next hop. Generally speaking there is a
need for a module/protocol that discovers and manages control plane
/data plane address bindings for the address spaces to be completely
separated. In this case, the TE Router ID could be just a network
unique number. Mandating that TE Router ID be a reachable IP address
eliminates the need of the mentioned above module รป the next hop data
plane TE Router ID could be used as a destination for IP packets
encapsulating the LSP setup (RSVP Path) message. Note that every TE
link ID could always be resolved to the link originating TE Router
ID.
An IP address may also be assigned to each physical interface
connected to the control plane network. Both numbered and unnumbered
links in the control plane may be supported. The control channels
are advertised by the routing protocol as normal links, which allows
the routing of RSVP-TE and other control messages between the LSRs
over the control plane network.
A physical interface address or a physical interface identifier is
assigned to each physical interface connected to the data plane. An
interface address or an interface identifier is logically assigned to
each TE-link end associated with the physical data channel in the
GMPLS domain. A TE link may be installed as a physical or logical
interface. A numbered link is identified by a network unique
identifier (e.g., an IP address) and an unnumbered link is identified
by the combination of TE Router ID and Interface ID. The existence of
both numbered and unnumbered links in the data plane should be
accepted. The recommended addressing for the numbered and unnumbered
links is also suggested in this document.
4.1. OSPF-TE
4.1.1. Router Address TLV
The Router Address TLV [RFC3630] is used for advertising the
association between the advertising Router ID and its TE Router ID.
The Router address TLV may be used for the CSPF calculation. This
address identifies the advertising router from a CSPF calculation's
point of view, i.e., it is the TE router ID associated with the
advertising Router.
Expires July 2005 [Page 5]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
A Router ID is also required for OSPF (non-TE) processing to identify
the LSR from an OSPF protocol point of view. Note that the Router ID
can be found in the header of each OSPF LSA advertised by the router.
It is recommended the Router address TLV should be the same as the TE
router ID for simplicity. It should, however, be possible to support
interoperation with nodes that use different addresses for the Router
address TLV and TE Router ID.
4.1.2. Link ID sub TLV
The Link ID sub-TLV [RFC3630] advertises the TE Router ID of the
remote end of TE link. For point-to-point links, this is the TE
Router ID of the neighbor. For multi-access links, this is the
interface address of the designated router. The Link ID is identical
to the contents of the Link ID field in the Router LSA for these link
types.
4.1.3. Local Interface IP Address
The Local Interface IP Address sub-TLV advertises the ID of the local
end of the numbered TE link. It must be network unique number and
MAY be a reachable IP address.
4.1.4. Remote Interface IP Address
The Remote Interface IP Address sub-TLV advertises the ID of the
remote end of the numbered TE link. It must be a network unique
number and may be reachable IP address.
4.2. ISIS-TE
To be discussed in future version of the document.
4.3. Use of Addresses in RSVP-TE
4.3.1. Session Object Destination IPv4 address
The IPv4 tunnel endpoint address in the Session Object [RFC3209]
specifies the TE Router ID of the egress.
4.3.2. Sender Template Object Sender IPv4 address
The IPv4 tunnel sender address in the Sender Template Object
[RFC3209] specifies the TE Router ID of the ingress.
Filling Session Object Destination Ipv4 Address and Sender Template
Object Sender IPv4 Address fields with TE Router IDs of LSP source
Expires July 2005 [Page 6]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
(ingress) and destination (egress) nodes respectively has the
following advantages over IP addresses unknown to the Traffic
Engineering or IDs of numbered TE links:
- TE Router IDs are known in the TE database; hence, unlike other IP
addresses (unknown to TE) they can be used as input for the path
computation.
- TE Router IDs are routable; therefore, unlike (potentially not
routable) IDs of numbered TE links they can be used as
destinations of targeted RSVP messages such as RSVP ResvConf.
Note that RSVP Notify messages are usually sent to addresses
explicitly specified in NotifyRequest objects. However, some GMPLS
implementations use LSP source and destination addresses as default
targets for RSVP Notify messages.
4.3.3. IF_ID RSVP-TE_HOP Object for Numbered Interfaces
1. IPv4 Next/Previous Hop Address: The IPv4 Next/Previous Hop Address
[RFC3473] in Path and Resv messages specifies the IP reachable
address of the control plane interface used to send those
messages, or the TE router ID of the node that is sending those
messages.
2. IPv4/IPv6 address in Value Field of TLV: In both the Path message
and the Resv message, the IPv4/IPv6 address in the value field of
TLV [RFC3471] specifies the associated data plane local interface
address of the downstream data channel belonging to the node
sending the Path message and receiving the Resv message. If the
interface upstream is different from that downstream, then another
TLV including the local interface address of the upstream data
channel belonging to the node sending the Path message and
receiving the Resv message may be also added to the TLV for
downstream. Note that data channels of both downstream and
upstream data channels are specified in each TLV from the
viewpoint of the sender of the Path message, in both the sent Path
message and received Resv message.
4.3.4. Explicit Route Object (ERO)
The IPv4/IPv6 address in the ERO provides a data-plane identifier of
an abstract node, TE node or TE link to be part of the signaled LSP.
We describe in section 6 the choice of incoming or outgoing interface
ID.
4.3.5. Record Route Object (RRO)
Expires July 2005 [Page 7]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
The IPv4/IPv6 address in the RRO provides a data-plane identifier of
either a TE node or TE link that is part of the established LSP.
We describe in section 6 the choice of incoming or outgoing interface
ID.
4.4. IP Packet Destination Address
The IP destination address of the packet that carries the RSVP-TE
message is a control-plane reachable address of the next hop or
previous hop node along the LSP route. It is recommended that a
stable control plane IP address of the next/previous hop node be used
as an IP destination address in RSVP-TE message.
A Path message is sent to the next hop node. This may not strictly
specify the next hop and use CSPF calculation. As a result, the TE
router ID of the next hop node will be obtained. It is recommended
that the TE router ID of the next hop node be used as an IP
destination address in RSVP-TE message.
A Resv message is sent to the previous hop node. Choices of the IP
destination of a Resv message are:
- The IP source address of the received IP packet containing the
Path message,
- A stable IP address of the previous node (found out by consulting
the TED and referencing the upstream data plane interface,
- The value in the received phop field.
4.5. IP Packet Source Address
The IP source address of the packet that carries the RSVP-TE message
is a reachable address of the node sending the message. It is
recommended that a stable IP address of the node be used as an IP
source address in RSVP-TE message. In case the IP source address of
the received IP packet containing the Path message is used as the IP
destination address of the Resv message, setting a stable IP address
in the Path message is beneficial for reliable control-plane
transmission. This allows for robustness when one of control-plane
interfaces is down.
5. Unnumbered Addressing
In this section, we describe unnumbered addressing used in GMPLS to
refer to different objects, their significance and best practices.
Unnumbered addressing is supported for a data plane.
Expires July 2005 [Page 8]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
5.1. OSPF-TE
Since GMPLS caters to PSC and non-PSC links, a few enhancements have
been made to the existing OSPF-TE and ISIS-TE protocols. The routing
enhancements for GMPLS are defined in [GMPLS-Rtg] and [GMPLS-OSPF].
5.1.1. Link Local/Remote Identifiers
Link Local/Remote Identifiers advertise IDs of an unnumbered TE
link's local and remote ends respectively. Those are numbers unique
within the scopes of the advertising LSR and the LSR managing link
remote end respectively. Note that these numbers are not network
unique and therefore could not be used as TE link end addresses on
their own. An unnumbered TE link end address is comprised of a TE
Router ID associated with the link local end followed by the link
local identifier [GMPLS-OSPF].
5.2. ISIS-TE
To be discussed in future version of the document.
5.3. Use of Addresses in RSVP-TE
An unnumbered address used for data plane identification consists of
the TE router ID and the associated interface ID.
5.3.1. IF ID RSVP-TE_HOP Object for Unnumbered Interfaces
The interface ID field in the IF_INDEX TLV specifies the interface of
the data channel for that unnumbered interface.
In both the Path message and the Resv message, the value of the
interface ID in the IF_INDEX TLV specifies the associated local
interface ID of the downstream data channel belonging to the node
sending the Path message and receiving the Resv message. If the
interface upstream is different from that downstream, then another
IF_INDEX TLV including the local interface ID of the upstream data
channel belonging to the node sending the Path message and receiving
the Resv message may be also added to the IF_INDEX TLV for
downstream. Note that both downstream and upstream data channels are
specified in each IF_INDEX TLV from the viewpoint of the sender of
the Path message, in both sent Path message and received Resv
message.
5.3.2. Explicit Route Object (ERO)
Expires July 2005 [Page 9]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
The interface ID field in the ERO specifies incoming and/or outgoing
interface of the TE-link to be used in nodes on the LSP route in the
data plane.
We describe in section 6 the choice of incoming or outgoing interface
ID.
5.4. Record Route Object (RRO)
The interface ID field in the RRO specifies incoming and/or outgoing
interface of the TE-link actually used in nodes on the LSP route in
the data plane.
We describe in section 6 the choice of incoming or outgoing interface
ID.
5.5. LSP_Tunnel Interface ID Object
The LSP_TUNNEL_INTERFACE_ID Object includes the LSR's Router ID and
Interface ID as described in [RFC3477] to specify a Forward Adjacency
Interface ID. The LSR's Router ID is the TE router ID.
5.6. IPv6 Addressing
TBD: IPv6 control planes and IPv6 data planes
6. RSVP-TE Message Content
6.1. ERO and RRO Addresses
6.1.1. Strict Subobject in ERO
The IPv4 prefix subobject or IPv6 prefix subobject in the Explicit
Route Object (ERO) includes an address specifying an abstract node
(i.e., a group of nodes), a simple abstract node (i.e., a specific
node), or a specific interface of a TE-link in the data plane in the
case of strict subobject [RFC3209].
In the case where Interface Address is included, it is recommended to
include in the IPv4/IPv6 prefix subobject the address of the Incoming
interface if it is not followed by the Label subobject as section
4.2.2 of RFC3209 implies; otherwise, it should include the address of
Outgoing interface if it is followed by the Label subobject as
section 5.1.1 of RFC3473 specifies.
This is the same in case of unnumbered. The Unnumbered Interface ID
Subobject [RFC3477] in EXPLICIT_ROUTE object includes the Interface
ID specifying the TE-link in the data plane.
Expires July 2005 [Page 10]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
It is recommended that the Unnumbered Interface ID Subobject include
the ID of Incoming interface if it is not followed by the Label
subobject and should include the ID of Outgoing interface if it is
followed by the Label subobject.
The label value of the identical unidirectional (i.e. either
downstream or upstream) resource between the upstream node and the
neighbor downstream node from the perspective of the upstream node
may be different from the perspective of downstream node. This is
typical in case of FSC, because the label value is the number
indicating the port/fiber. This is possible in case of LSC, because
the label value is the number indicating the lambda but may not be
the value directly indicating the wavelength value (e.g., 1550 nm).
The value of label MUST indicate the value from the perspective of
the sender of the object/TLV [RFC3471]. This rule MUST be applied to
all types of object/TLV.
Therefore, the label field in Label ERO subobject MUST include the
value of the label for the upstream node side of the resource.
6.1.2. Loose Subobject in ERO
A subobject in an ERO may be marked as a loose hop [RFC3209]. In this
case the content may be an IPv4 or IPv6 prefix subobject that
specifies the address of an abstract node (i.e., a group of nodes),
or a simple abstract node (i.e., a specific node).
In the case where a simple abstract node is specified, an IPv4 or
IPv6 prefix subobject includes TE node ID.
There may be a special case where the Interface ID is specified in
the Loose subobject in the ERO in order to control on what interface
the path is set up. Here, there is no way to specify in ERO whether
a subobject is associated with the incoming or outgoing TE link.
This is unfortunate because the address specified in a loose
subobject is used as a target for the path computation, and there is
a big difference for the path selection process whether the intention
is to reach the target node over the specified link (the case of
incoming TE link) or to reach the node over some other link, so that
it would be possible to continue the path to its final destination
over the specified link (the case of outgoing TE link).
In the case where the IPv4 prefix subobject or the IPv6 prefix
subobject in the ERO is marked as a loose hop and specially specifies
an interface, the subobject SHOULD include the address of the
Incoming interface specifying the TE-link in the data plane.
Expires July 2005 [Page 11]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
In the special case where the Unnumbered Interface ID Subobject with
Loose bit set is included in ERO, the subobject should include the ID
of the Incoming interface specifying the TE-link in the data plane.
A subobject marked as a loose hop in ERO should never include an
identifier (i.e., address or ID) of outgoing interface.
6.1.3. RRO
The IPv4 address Subobject or the IPv6 address Subobject in the
Record Route Object (RRO) in the PATH message SHOULD include the
address of the Outgoing interface specifying the TE-link in the data
plane.
The IPv4 address Subobject or the IPv6 address Subobject in the
Record Route Object (RRO) in the RESV message SHOULD include the
address of the Incoming interface specifying the TE-link in the data
plane.
The Unnumbered Interface ID subobject in the Record Route Object in
the PATH message SHOULD also include the interface ID of the Outgoing
interface specifying the TE-link in the data plane.
The Unnumbered Interface ID subobject in the Record Route Object in
the RESV message SHOULD also include the interface ID of the Incoming
interface specifying the TE-link in the data plane.
Incoming and outgoing always refer to the direction of data on a
unidirectional LSP.
The label value of the identical unidirectional (i.e. either
downstream or upstream) resource between the upstream node and the
neighbor downstream node from the perspective of the upstream node
may be different from the perspective of the downstream node.
The value of the label must indicate the value from the perspective
of the sender of the object/TLV [RFC3471]. This rule must be applied
to all types of object/TLV.
Therefore, the label field in the Label RRO subobject in the Path
message must include the value of the label for the upstream node
side of the resource; the label field in the Label RRO in the Resv
message must include the value of the label for the downstream node
side of the resource.
The IPv4/IPv6 address Subobject in the Record Route Object (RRO) may
include TE node ID. However, it is recommended to include the
Expires July 2005 [Page 12]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
interface ID rather than the TE node ID, because the interface ID has
more information and is more helpful from the viewpoint of
maintenance than node ID.
6.2. Forwarding Destination of Path Message with ERO
The final destination of the Path message is the Egress node that is
specified by the tunnel end point address in the Session object.
The Egress node must not forward the corresponding Path message
downstream.
In the case where the EXPLICIT_ROUTE object (ERO) includes the
Interface address or Interface ID as the last element for the Egress
control [EGR-CNT], the Egress node MUST NOT forward the corresponding
Path message downstream.
7. GMPLS Control Plane
7.1. Control Channel Separation
In GMPLS, a control channel can be separated from the data channel
and there is not necessarily a one-to-one association of a control
channel to a data channel. Two adjacent nodes may have multiple IP
hops between them in the control plane.
In this discussion, the "control plane address" identifies a node to
other nodes in the control plane. It MUST be used in RSVP-TE Hop
objects as the Next/Previous Hop addresses, as the IP
source/destination addresses in the innermost IP header of all
signaling messages, and to identify neighbors for reliable messaging
[RFC2961]. Nodes can have multiple control plane addresses.
There are two broad types of separated control planes: native and
tunneled. These differ primarily in the nature of encapsulation used
for signaling messages, which also results in slightly different
address handling with respect to the control plane address.
7.2. Native Control Plane
A native control plane runs directly over a physical interface.
Signaling packets are encapsulated in a single IP header and
necessary Layer-2 headers in order for the source and destination
interfaces to communicate at an IP layer. All implementations MUST
support a native control plane. Native control planes can run out-of-
band (e.g. over an Ethernet or other interface), or in-fiber.
Expires July 2005 [Page 13]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
The control plane address is set to the IP address of the physical
interface. This control plane address MUST be used as the source
(destination, respectively) address in the IP header of all RSVP-TE
messages sent from (to) the node, and in the Hop objects as above.
If the control plane interface is unnumbered, the RECOMMENDED value
for the control plane address is the TE Router-ID.
Implementations MUST support addressing and sending messages to
arbitrary neighbor control plane addresses (either configured or
discovered), such as private addresses or TE Router-ID.
Implementations MUST support receiving messages addressed to their TE
Router-ID on all point-to-point control interfaces, numbered or
unnumbered. Implementations MAY support receiving messages addressed
to their TE Router-ID on broadcast or NBMA interfaces, perhaps using
some form of proxy-ARP for reachability.
For the case where two adjacent nodes have multiple IP hops between
them in the control plane and IP tunneling is not set for the control
channel, implementations MUST use the mechanisms of section 8.1.1 of
[HIERARCHY] in addition to the mechanisms of section 7.18 of
[RFC3945]. Note that section 8.1.1 of [Error! Bookmark not defined.]
applies to this case by replacing all instances of the words "FA-LSP"
(Forwarding Adjacency) with "TE-LINK" in case the LSP is not tunneled
through an FA-LSP but a normal TE-link.
Several mechanisms for the case are described below.
All RSVP-TE messages MUST NOT include the Router Alert Option.
PathErr message SHOULD contain an IF_ID RSVP_HOP object. (Note: a
PathErr does not normally carry an IF_ID RSVP_HOP object.)
With respect to Time-To-Live (TTL), one should note that messages may
traverse multiple IP hops. The IP TTL applied to RSVP-TE messages
sent on a separated control channel SHOULD be the same as for any
network message sent on that network. Specific values like 1 or 255
MAY be used if specific aims are desired, e.g. ensuring all RSVP
messages travel only one hop. Implementations sending RSVP messages
on a separated control plane SHOULD explicitly set the IP TTL for
every message generated. Implementations receiving RSVP-TE messages
on a separated control plane MUST NOT compare the RSVP and IP TTL.
Instead, checking received IF_ID RSVP_HOP object in the way described
in section 8.1.1 of [Error! Bookmark not defined.] is essential.
7.3. Tunneled Control Plane
Expires July 2005 [Page 14]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
A tunneled control plane runs on a virtual point-to-point tunnel
interface, which in turn may use an underlying physical interface to
reach the neighbor. RSVP-TE packets (including RSVP and IP headers)
are encapsulated in an additional Layer-3 header which is used to
transit a control network. A common example of tunnel technologies
is GRE encapsulation [RFC2784].
In the common case of GRE tunnel encapsulation, the physical
interface IP address is used in the outermost IP header and serves to
route the signaling packet through the DCN. The control plane
address is set to the address of the virtual tunnel interface. This
control plane address is used in the innermost IP header, and in
other uses for RSVP as discussed above. If the virtual tunnel
interface is unnumbered, the RECOMMENDED value for the control plane
address is the TE Router-ID.
For a tunneled control plane, the inner RSVP and IP messages traverse
exactly one IP hop. The IP TTL of the outermost IP header SHOULD be
the same as for any network message sent on that network.
Implementations receiving RSVP-TE messages on the tunnel interface
MUST NOT compare the RSVP TTL to either of the IP TTLs received.
Implementations MAY set the The RSVP TTL to be the same as the IP TTL
in the innermost IP header.
There are many advantages to using a tunneled control plane. GMPLS
control messages are encapsulated from being intercepted in the DCN
by MPLS/TE capable nodes. Also, this encapsulation may be required
for interoperation between a GMPLS/TE and IP/MPLS network. Multiple
parallel unnumbered tunnels provide good redundancy properties by
having the local and neighbor control plane address independent of
the physical interface used for communication. For these reasons, it
is RECOMMENDED that all implementations SHOULD support GRE-based
tunneled control plane. It is further RECOMMENDED that, for all out-
of-band control plane deployments, a tunneled control plane SHOULD be
preferred over a native control plane, the tunnel interface
preferably be unnumbered and the control plane address SHOULD be the
TE Router-ID.
7.4. Separation of Control and Data Plane Traffic
PSC-capable nodes implementing an OOB control plane (perhaps to
communicate with an optical switch) MUST NOT use the OOB control
plane for data traffic. For example, in the case of MPLS service
running on top of a GMPLS LSP, if the peer PSC device is reachable
via both the control plane and the data plane, control protocols such
as LDP MUST NOT form adjacencies over the control plane interfaces.
This may be provided by a combination of implementation features and
deployment guidelines. For example, implementations MAY use specific
Expires July 2005 [Page 15]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
configured interfaces for sending GMPLS control messages irrespective
of routing, and these may be deployed such that all routed traffic is
routed over the data channel interfaces. Otherwise, control plane
interfaces may be configured to not exchange protocol hellos for
other protocols.
8. Security Considerations
This document does not define new protocols. Consequently, no new
security considerations arise.
9. Full Copyright Statement
Copyright (C) The Internet Society (2005).
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.
10. Intellectual Property
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 IETF's procedures with respect to rights in IETF 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.
Expires July 2005 [Page 16]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
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.
11. Acknowledgement
The authors would like to thank Adrian Farrell for the helpful
discussions and the feedback he gave on the document.
12. Authors' Addresses
Kohei Shiomoto
NTT Network Service Systems Laboratories
3-9-11 Midori
Musashino, Tokyo 180-8585
Japan
Email: shiomoto.kohei@lab.ntt.co.jp
Rajiv Papneja
Isocore Corporation
12359 Sunrise Valley Drive, Suite 100
Reston, Virginia 20191
United States of America
Phone: +1-703-860-9273
Email: rpapneja@isocore.com
Richard Rabbat
Fujitsu Labs of America, Inc.
1240 East Arques Ave, MS 345
Sunnyvale, CA 94085
United States of America
Phone: +1-408-530-4537
Email: richard.rabbat@us.fujitsu.com
13. Contributors
Yumiko Kawashima
NTT Network Service Systems Lab
Email: kawashima.yumiko@lab.ntt.co.jp
Ashok Narayanan
Cisco Systems
Email: ashokn@cisco.com
Expires July 2005 [Page 17]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
Eiji Oki
NTT Network Service Systems Laboratories
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
Email: oki.eiji@lab.ntt.co.jp
Lyndon Ong
Ciena Corporation
Email: lyong@ciena.com
Vijay Pandian
Sycamore Networks
Email: Vijay.Pandian@sycamorenet.com
Hari Rakotoranto
Cisco Systems
Email: hrakotor@cisco.com
14. References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, IETF RFC 2026, October 1996.
[RFC3945] Mannie, E., ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture," RFC 3945, October 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, IETF RFC 2119, March 1997.
[RFC3630] Katz, D., Kompella, K. et al., "Traffic Engineering (TE)
Extensions to OSPF Version 2," RFC 3630, September 2003.
[RFC3477] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)," RFC 3477, January 2003.
[RFC2328] Moy, J., "OSPF Version 2," RFC 2328, April 1998.
[RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments," RFC 1195, December 1990.
[RFC3471] Berger, L., ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description," RFC
3471, January 2003.
Expires July 2005 [Page 18]
draft-shiomoto-ccamp-gmpls-addressing-00 January 2005
[GMPLS-Rtg] K. Kompella, Y. Rekhter (Eds.), "Routing Extensions in
Support of Generalized Multi-protocol Label Switching,"
draft-ietf-ccamp-gmpls-routing-09.txt, October 2003.
[GMPLS-OSPF] K. Kompella, Y. Rekhter (Eds.), "OSPF Extensions in
Support of Generalized Multi-protocol Label Switching,"
work in progredraft-ietf-ccamp-gmpls-ospf-gmpls-
extensions-12.txt, October 2003.
[RFC3209] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels," RFC 3209, December 2001.
[RFC3473] Berger, L., ed. "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions," RFC
3473, January 2003.
[EGR-CNT] Berger, L., "GMPLS Signaling Procedure For Egress
Control," work in progress, draft-ietf-ccamp-gmpls-
egress-control-03.txt, August 2004.
[RFC2961] Berger, L., Gan, D., Swallow, G., et al., "RSVP Refresh
Overhead Reduction Extensions," RFC 2961, April 2001.
[HIERARCHY] Kompella, K. and Rekhter, Y., "LSP Hierarchy with
Generalized MPLS TE," work in progress, draft-ietf-mpls-
lsp-hierarchy-08.txt, March 2002.
[RFC2784] Li, T., Farinacci, D. et al., "Generic Routing
Encapsulation (GRE)," RFC 2784, March 2000.
Expires July 2005 [Page 19]