Internet DRAFT - draft-shiomoto-ccamp-cplane-arch
draft-shiomoto-ccamp-cplane-arch
CCAMP Working Group Kohei Shiomoto (NTT)
Internet Draft Rajiv Papneja (ISOCORE)
Expiration Date: April 2004 Bijan Jabbari (ISOCORE)
October 2003
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 addresses control plane architecutre in GMPLS enabled IP-
Optical networks. Two different control plane architectures are consid-
ered: symmetical and asymmetrical control plane architectures. Address-
ing (router-ID, control plane address, and TE link address) and RSVP
message handling are discussed for both architectures.The document also
recommends normal practises for identification of TE links. Interwork
between symmetrical and asymmetrical control plane is addressed.
Shiomoto [Page 1]
draft-shiomoto-ccamp-cplane-architecture-00.txtOctober 2003
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
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
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 distinctive feature for TDM, wavelength, fiber swtching
networks. Control information that includes routing and singnaling
packets are transported over control plane networks. Separation between
control and data planes mandates a different treatment for control pack-
ets as in conventional IP/MPLS protocols,there is almost no distinctions
in the path taken by control and data packets in IP/MPLS networks.
Shiomoto [Page 2]
draft-shiomoto-ccamp-cplane-architecture-00.txtOctober 2003
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 IP header of
the Path message: (1) ingress-to-egress method and (2) hop-by-hop
method. Source and destination addresses of IP header of the Path mes-
sage are set to the ingress and egress nodes of LSP in the ingress-to-
egress method while they are set to the the current hop and the next hop
nodes, where the Path message is sent from the current to the next hop
node.
RSVP-TE is developed by extending RSVP developed for resource reserva-
tion for Intserv model [RFC2205] and now is used to set up explicitly
routed LSP (ER-LSP) in MPLS networks [RFC3209]. RSVP-TE adopts the
ingress-to-egress method and uses addresses of ingress and egress of ER-
LSP as the source and destination addresses of Path message with router
alert option bit set. Path message may carry explicit route object
(ERO) and the intermediate node inspcets the Path message and processes
it to determine the appropriate next hop. Path message is routed along
with the path specified in ERO.
This mechanism works in IP/MPLS network because there is almost no dis-
tinction as to how to forward control packet and data packet. It does
not, however, work in GMPLS network because control plane network is
constructed independent of data plane network topology in GMPLS network.
For example, control plane network could be constructed as a native
layer-two network or by using point-to-point GRE tunnels or IP-in-IP
tunnels. While the ingress node and egress node are neighbors from con-
trol plane perspective, they will not be neighboring nodes from the data
plane perspective. The Path message cannot be inspected by intermediate
nodes for data plane consequently the LSP setup, therfore fails. The
ingress node is the neighbor node of the egress node in control plane
perspective while the ingress node is not in the data plane perspective.
After the ingress node sends the Path messaga out, the egress node
receives it without allowing the intermediate nodes to inspect the Path
message in data plane prespective with the result of the LSP setup fail-
ure with 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 messege and the next hop address is set to the destination address
of the Path message. The Path message is routed along with the route
along with which the LSP is to be routed in data plane network. Gener-
alized Label request replaces the MPLS label request defined in the
[RFC3209] in the GMPLS. It is required to carry the switching type
requested by the ingress for 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(generalized payload identifier), this value is
Shiomoto [Page 3]
draft-shiomoto-ccamp-cplane-architecture-00.txtOctober 2003
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 values should be adopted. The G-PID
range is open as defined in the [RFC-3471] allowing room for optional
values.
3.3. Impcat on OSPF
Since GMPLS caters to the PSC and non-PSC links there are few enhance-
ments that are made to the exisiting OSPF-TE and ISIS-TE. The routing
enhancements for the GMPLS is defined in the document [GMPLS-Routing]
and [GMPLS-OSPF]. Once the Label switched paths have been established,
document [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, important that all routing equipment are capable of qualify-
ing the TE links on the switching capabilities. The OXCs will not adver-
tise the link switching capability to be PSC. The CSPF algorithms on the
IP routers have to be modified to incoporate the path computation across
interfaces supporting various switching capabilities. Addresing and
RSVP handling of symmetrical control plane is different from those of
asymmetrical control plane.
3.4. Outline of this document
In this document we address issues on RSVP handling in symmetrical and
asymmetrical control plane and inter-work between both control plane
architecture. For addressing we address router-ID, control plane
address, and data plane address for both methods. For RSVP handling we
address Path message routing, ERO processing, and HOP processing for
both methods. For routing extensions we address the handling of non-PSC
devices in the cspf computation and expected behavior of the clients.
Moreover we address inter-work between both methods.
4. Control plane network architecture
4.1. Addressing
Addresses are assgined to each node and link in both control and data
plane in GMPLS networks. Router-ID is defined to identify the router
and could be an non-IP address. Router-ID should be defined as loop-
back address and be advertized by routing protocol. Loop-back address
Shiomoto [Page 4]
draft-shiomoto-ccamp-cplane-architecture-00.txtOctober 2003
is stable address and therefore is not assigned to any of control and
data plane address because any link failure causes the router-ID to
become unreachable. Control plane address is assigned to each physical
interface to control plane network. There is ambiguity in the implemen-
tations to use the control channel address as the router-id for reacha-
bility purposes. It is receommended that all the optical devices should
support the notion of loopback address, which may be used as the router-
id. Both numbered and unnumbered link control plane interface should be
supported. Data plane address is assigned to each physical interface to
data plane network and must be used as the TE-links in the GMPLS domain.
Both numbered and unnumbered link data plane interface should be sup-
ported. If the control channel used is a point-to-point link, it is
recommended that it should be unnumbered interface. If 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 into routing as notmal 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 which has TE properties and pro-
vides information about the physical resources attached to it and can be
used by the CSPF alogorithm for computing the paths for the GMPLS LSP
setup. The TE links should not be confused with the addressing of the
control channel and should be treated as seperate from the addressing
used in the IP layer. Once the GMPLS 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 may be component links if the link type is using link bundling
[lINK-BUNDLE]. The best practise to ensure seperation of the control
channel addressing and TE links addressing is to assign unique address-
ing to the data links (physical interfaces) connecting the routing
equipment to the transport devices and use them as TE links. This sce-
nario is valid only for numbered links. If the links are unnumbered then
source and desitination loopback addresses with the Interface-ID is used
in the ERO at the head-end of the LSP setup. TE links liveliness is an
important factor that an LSR should verify before advertizing to its
neighbors. This ensures that no stale entries are advertized in the TE
link databases once there has been a physical link failure. Also, once
the GMPLS LSP is used as a link in the IP layer, t he TE livliness
ensures that the head-end and tail-end of the GMPLS LSP view the same
status of the LSP. It has been observed that if restart is not sup-
ported and for some reason a fiber cut happens at the ingress, and if it
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
as a dead LSP. This LSP will still be operational in the IP layer and
will be used to carry the traffic.
Shiomoto [Page 5]
draft-shiomoto-ccamp-cplane-architecture-00.txtOctober 2003
4.2. Symmetrical and asymmetrical control plane
In this document, we define two control plane architectures: symmetrical
and asymmetrical control plane. Control plane network can be configured
in the same topology as data plane topology. We call this conrol plane
architecture "symmetrical" control plane. Figure 1 shows the example of
symmetrical control plane. Each node consists of 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. Node 3 is adjacent to node 2 and node 4 in
both control and data plane networks. Node 4 is adjacent to node 3 in
both control and data plane networks.
Control plane
+---+ +---+ +---+ +---+
|C1 +-------+C2 +-------+C3 +-------+C4 |
+---+ +---+ +---+ +---+
==========================================
Data plane
+---+ +---+ +---+ +---+
|D1 +-------+D2 +-------+D3 +-------+D4 |
+---+ +---+ +---+ +---+
Figure 1 Symmetrical control plane.
Control plane network can be configured in the topolgoy different from
that of the data plane network. We call this control plane architecture
"asymmetrical" control plane. Figure 2 shows the example of asymmetri-
cal control plane. Control plane network is constructed as a native
layer-2 network. Node 1, 2, 3, and 4 are adjacent to one another in
control plane network. On the other hand, node 1 is adajacent to node 2
but not to node 3 in data plane network, for instance. Node 1 is adja-
cent to node 2 in data plane network. Node 2 is adjacent to node 1 and
node 3 in data plane network. Node 3 is adjacent to node 2 and node 4
in data plane network. Node 4 is adjacent to node 3 in data plane net-
work.
Shiomoto [Page 6]
draft-shiomoto-ccamp-cplane-architecture-00.txtOctober 2003
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
Symmetric control plane is configured in either physical or logical
sense. Physically symmetrical control plane is configured. In-fiber
and out-of-fiber control channel can be configured. In-fiber contorl
channel 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 dedicated physical link in parallel with
data plane link. Logical symmetrical control plane is configured even
though physical control plane topology is different from that of data
plane topology. IP-in-IP [RFC2003] and GRE [RFC2784] tunneling can be
used to configure logical symmetrical control plane over 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 sym-
metrical control plane network. In the ingress-to-egress method, router
alert option in the IP header of the Path message is set so that the
intermidiate 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 with the route along with which the Path message is for-
warded. Path message is routed according to the ERO object as specified
in [RFC3209]. If the ERO deos not exist in the Path message, the Path
message is forwarded in the same way as the normal IP packet, i.e., the
Shiomoto [Page 7]
draft-shiomoto-ccamp-cplane-architecture-00.txtOctober 2003
forwarding table is consulted to determine the next hop. ERO consists
of a combination of loose and strict subobjects. If the top subobject
of ERO is loose, the next hop is determined according to the local pol-
icy decision. The Path message must be routed in the same direction in
the conrol plane network as the LSP is routed in the data plane network.
Therefore the Path message should be routed so that the sufficient
resource is available for the LSP along with the route in the data plane
network.
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 exitly 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 plane the Path message can take different route if
we use ingress-to-egress method because the control plane topology is
different from data plane topology. We should use the hop-by-hop method
in asymmetrical control plane [10.2, RFC3473]. We may use the ingress-
to-egress method by using ERO. The intermidiate node may insert strict
subobjects in ERO in order to route the Path message along with 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.
Shiomoto [Page 8]
draft-shiomoto-ccamp-cplane-architecture-00.txtOctober 2003
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-bun-
dle-04.txt]
Shiomoto [Page 9]
