CCAMP Working Group Kohei Shiomoto (NTT)
Internet Draft Rajiv Papneja (ISOCORE)
Expiration Date: June 2004 Bijan Jabbari (ISOCORE)
February 2004
Control plane architecture in GMPLS networks
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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes practice for designing control plane in GMPLS
enabled IP-Optical networks. Two different control plane architectures
are considered: symmetrical and asymmetrical control plane architec-
tures. Addressing (router-ID, control plane address, and TE link
address) and RSVP message handling are discussed for both architectures.
The document also recommends best practices for identification of TE
links. Interworking between symmetrical and asymmetrical control planes
is also finally discussed.
Shiomoto [Page 1]
draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004
1. Author information
This document is the product of the following authors collaboration.
Kohei Shiomoto (NTT)
NTT Network Innovation Laboratories
3-9-11 Midori,
Musashino, Tokyo 180-8585, Japan
Email: shiomoto.kohei@lab.ntt.co.jp
Rajiv Papneja (Isocore)
Isocore Corporation
8201 Greensboro Drive
Suite 100, Mclean, VA 22102
Email: rpapneja@isocore.com
Bijan Jabbari (Isocore)
Isocore Corporation
8201 Greensboro Drive
Suite 100, McLean, VA 22102
Email:bjabbari@isocore.com
Richard Rabbat
Fujitsu America Limited
Vijay Pandayan
Sycamore Network
TBD
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.
3. Introduction
Shiomoto [Page 2]
draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004
3.1. Control plane separation
Generalized MPLS (GMPLS) is currently being standardized in the IETF as
a set of intelligent IP routing and signaling protocols that can be used
to configure different switching networks: packet, layer-2, TDM, wave-
length, fiber switching capabilities. Separation between control and
data planes is a distinctive feature for TDM, wavelength, fiber switch-
ing networks. Control information that includes routing and signaling
packets are transported over control plane networks. Separation between
control and data planes mandates a different treatment for control pack-
ets than in conventional IP/MPLS protocols where there is almost no dis-
tinction in the path taken by control and data packets in IP/MPLS net-
works.
3.2. Impact on RSVP
Two methods may be used in the symmetrical control plane as to which
addresses are used for source and destination address of the IP header
of the Path message: (1) ingress-to-egress method and (2) hop-by-hop
method. Source and destination addresses of the IP header of the Path
message are set to the ingress and egress nodes of LSP in the ingress-
to-egress method. They are set to the current hop and the next hop
nodes, when the IP header addresses are set using the hop-by-hop node.
RSVP-TE adopts the ingress-to-egress method with the router alert option
bit set. The Path message may carry explicit route object (ERO). Inter-
mediate nodes inspect the Path message and process it to determine the
appropriate next hop. The Path message is routed along the path speci-
fied in the ERO.
This mechanism works in IP/MPLS network because there is almost no dis-
tinction as to how to forward control and data packets. It does not,
however, work in GMPLS network because the control plane network is con-
structed independently of the data plane network topology and thus may
be different. For example, the control plane network could be con-
structed as a native layer-2 network or by using point-to-point GRE tun-
nels or IP-in-IP tunnels. While the ingress and egress nodes are neigh-
bors from the control plane perspective, they may not be neighboring
nodes from the data plane perspective. The Path message cannot be
inspected by intermediate nodes, the LSP setup therefore fails. The
ingress node is the neighbor of the egress node from the control plane
perspective while the it is not from the data plane perspective. After
the ingress node sends the Path message out, the egress node receives it
Shiomoto [Page 3]
draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004
without allowing the intermediate nodes to inspect the Path message
resulting in the failure of the LSP setup when using the ingress-to-
egress method.
The hop-by-hop method should be used in such network. With the hop-by-
hop method, the previous hop address is set to the source address of the
Path message and the next hop address is set to the destination address
of the Path message. The Path message is routed along the route that
the LSP is to be routed on in the data plane network. A Generalized
Label request replaces the MPLS label request defined in the [RFC3209].
It is required to carry the switching type requested by the ingress of
the LSP, LSP encoding type defining the encoding type that will be used
with the data associated with the LSP. It also defines the G-PID (Gen-
eralized Payload IDentifier): this value is associated with the payload
type requested by the client layer of that LSP. Various implementations
support different G-PID values, which causes interworking issues at the
egress. A liberal policy in regards to accepting different payload val-
ues should be adopted.
3.3. Impact on OSPF
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-Routing] and [GMPLS-OSPF].
Once the Label Switched Paths have been established,
[LSP-HIER] defines how to associate TE properties with the links formed
by Label Switched Paths. All the optical devices will advertise the
links as either FSC, LSC, L2SC, or TDM capable and all IP routers will
advertise their own links as PSC capable only. It is, therefore, impor-
tant that all routing equipment be capable of qualifying the TE linksf
switching capabilities. For example, OXCs will not advertise the link
switching capability to be PSC. The CSPF algorithms on the IP routers
have to be modified to allow for path computation across interfaces sup-
porting various switching capabilities. Addressing and RSVP handling of
a symmetrical control plane are different from those of an asymmetrical
control plane.
3.4. Outline of this document
In this document we address issues on RSVP handling in symmetrical and
asymmetrical control planes and inter-work between both control planes.
With respect to addressing, we look at router-ID, control plane address,
Shiomoto [Page 4]
draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004
and data plane address for both methods. With respect to RSVP handling,
we address Path message routing, ERO processing, and HOP processing.
With respect to routing extensions, we address the handling of non-PSC
devices in the CSPF computation and expected behavior of the clients.
Lastly, we address inter-working between both methods.
4. Control plane network architecture
4.1. Addressing
Addresses are assigned to each node and link in both control and data
plane in GMPLS networks. A Router-ID is defined to identify the router
and could be a non-IP address. Router-ID should be defined as loopback
address and be advertised by the routing protocol. The loop-back
address is a stable address and therefore is not assigned to any control
or data plane address because any link failure causes the router-ID to
become unreachable. A control plane address is assigned to each physi-
cal interface to the control plane network. There is an ambiguity in
the implementations that manifests itself in the use of the control
channel address as the router-id for reachability purposes. It is rec-
ommended that all the optical devices should support the notion of a
loopback address, which may be used as the router-id. Both numbered and
unnumbered link control plane interface should be supported. A data
plane address is assigned to each physical interface to the data plane
network and must be used as the address of the TE-links in the GMPLS
domain. Both numbered and unnumbered link data plane interface should
be supported. If the control channel used is a point-to-point link, it
is recommended that it should be an unnumbered interface. If a numbered
point-to-point connection for control channel is used, the endpoints of
the GRE should not be used as the TE links. These control channels are
advertised by the routing protocol as normal links, which allows the
routing of RSVP and other related control channels.
4.1.1. Identification of TE links in the GMPLS control plane
TE links are defined as logical links that have TE properties and pro-
vide information about the physical resources attached to them; they can
be used by the CSPF algorithm for computing the paths. The TE links
should not be confused with the addressing of the control channel and
should be treated as separate from the addressing used in the IP layer.
Once the LSPs are established, the IP layer could use these LSPs as TE
links [LSP-HIER]. Generally, TE links in the GMPLS layer are defined by
the combination of local identifier, label and possibly component links
if the link type uses link bundling [lINK-BUNDLE]. The best practice to
Shiomoto [Page 5]
draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004
ensure separation of the control channel addressing and TE links
addressing is to assign unique addresses to the data links (physical
interfaces) connecting the routing equipment to the transport devices
and use them as TE links. This scenario is valid only for numbered
links. If the links are unnumbered then source and destination loopback
addresses with the Interface-ID are used in the ERO at the head-end of
the LSP. TE linksf liveliness is an important factor that an LSR should
verify before advertising to its neighbors. This ensures that no stale
entries are advertised in the TE link databases once there has been a
physical link failure. Also, once the LSP is used as a link in the IP
layer, the TE liveliness ensures that the head-end and tail-end of the
GMPLS LSP have the same view of the status of the LSP. It has been
observed that if restart is not supported and a fiber cut happens at the
ingress that signals the LSP with new tunnel-ID, the transport devices
and egress will maintain the state of the old LSP but the Ingress will
consider it to be a dead LSP. This LSP will still be operational at the
IP layer and will be used to carry the traffic.
4.2. Symmetrical and asymmetrical control plane
We define two control plane architectures: symmetrical and asymmetrical
control plane. A control plane network can be configured with the same
topology as the data planefs. We call this control plane architecture
"symmetrical" control plane. Figure 1 shows the example of symmetrical
control plane. Each node consists of a control plane part and data
plane part. Node 1 is adjacent to node 2 in both control and data plane
networks. Node 2 is adjacent to node 1 and node 3 in both control and
data plane networks, etc.
A control plane network topology can be different from that of the data
plane network. We call this control plane architecture "asymmetrical"
control plane. Figure 2 shows the example of asymmetrical control
plane. Control plane network is constructed as a native layer-2 net-
work. Node 1 is adjacent to node 3 in control plane but not in data
plane.
Shiomoto [Page 6]
draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004
Control plane
+---+ +---+ +---+ +---+
|C1 +-------+C2 +-------+C3 +-------+C4 |
+---+ +---+ +---+ +---+
==========================================
Data plane
+---+ +---+ +---+ +---+
|D1 +-------+D2 +-------+D3 +-------+D4 |
+---+ +---+ +---+ +---+
Figure 1 Symmetrical control plane.
Control plane
+-----------+-----------+-----------+
| | | |
+-+-+ +-+-+ +-+-+ +-+-+
|C1 | |C2 | |C3 | |C4 |
+---+ +---+ +---+ +---+
==========================================
Data plane
+---+ +---+ +---+ +---+
|D1 +-------+D2 +-------+D3 +-------+D4 |
+---+ +---+ +---+ +---+
Figure 2 Asymmetrical control plane.
5. Symmetric control plane
5.1. Topology implementation
A symmetric control plane is configured in either the physical or logi-
cal sense. In-fiber and out-of-fiber control channel can be configured.
An in-fiber control channel that includes optical supervisory channel
can be used for optical networks while DCC bytes can be used for
SDH/SONET networks. Out-of-fiber control channel includes a dedicated
physical link in parallel with the data plane link. A logically symmet-
rical control plane can be configured even though the physical control
plane topology is different from that of the data plane. IP-in-IP
[RFC2003] and GRE [RFC2784] tunneling can be used to configure logically
Shiomoto [Page 7]
draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004
symmetrical control plane over a physically asymmetrical control plane.
5.2. RSVP handling
5.2.1. Message routing
Both ingress-to-egress method and hop-by-hop method can be used in a
symmetrical control plane network. In the ingress-to-egress method, the
router alert option in the IP header of the Path message is set so that
the intermediate nodes inspect it. The Path message is forwarded to the
egress node. Intermediate nodes inspect the Path message and the LSP is
set up along the route on which the Path message is forwarded. The Path
message is routed according to the ERO object as specified in [RFC3209].
If the ERO does not exist in the Path message, the Path message is for-
warded in the same way as the normal IP packet, i.e., the forwarding ta-
ble is consulted to determine the next hop. An ERO consists of a combi-
nation of loose and strict subobjects. If the top subobject of ERO is
loose, the next hop is determined according to the local policy deci-
sion. The Path message must be routed in the same direction in the con-
trol plane network as the LSP is routed in the data plane network.
Therefore the Path message should be routed so that sufficient resources
are available for the LSP.
In the hop-by-hop method, the Path message is addressed to the next hop
node [10.2, RFC3473]. In the hop-by-hop method, the Router Alert option
should not be set. RSVP was designed to handle dynamic (non-explicit)
path changes and non RSVP hops along the path and therefore the source
and destination address of IP header of the Path message is set to the
ingress and egress nodes of the "session". In generalized signaling,
routes are usually explicitly signaled hops that cannot allocate labels
and cannot exist in the path of an LSP in the data plane network.
6. Asymmetric control plane
6.1. RSVP handling
6.1.1. Message routing
In asymmetric control planes, the Path message can take a different
route if we use ingress-to-egress method. We should use the hop-by-hop
method in asymmetrical control plane [10.2, RFC3473]. We may use the
ingress-to-egress method when using EROs. The intermediate node may
insert strict subobjects in the ERO in order to route the Path message
Shiomoto [Page 8]
draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004
along the route with sufficient resource for the LSP.
7. Inter-work between symmetric and asymmetric control plane network
Both the ingress-to-egress and hop-by-hop methods can be used in symmet-
ric control plane network. Both the ingress-to-egress and hop-by-hop
methods can be used in asymmetric control plane network. All combina-
tion
should be inter-operable. Solution for inter-operability will be
developed in the future version of this draft.
8. Security considerations
Security issues are not discussed in this draft.
9. Reference
[RFC2003] C. Perkins, "IP Encapsulation within IP," RFC2003, October
1996.
[RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specifica-
tion," RFC2205, September 1997.
[RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, "Generic
Routing Encapsulation (GRE)," RFC 2784, March 2000.
[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swal-
low, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC3209, December
2001.
[RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Extensions," January 2003.
[LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with General-
ized MPLS TE", [RFC Ed Queue] [draft-ietf-mpls-lsp-hierarchy-08.txt]
[GMPLS-OSPF] Kompella, K., and Rekhter, Y. (Editors), "OSPF Extensions
in Support of Generalized MPLS", (work in progress) [draft-ietf-ccamp-
ospf-gmpls-extensions-11.txt]
[LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling
in MPLS Traffic Engineering", [RFC Ed Queue] [draft-ietf-mpls-
Shiomoto [Page 9]
draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004
bundle-04.txt]
Shiomoto [Page 10]