Network Working Group E. Roch
Internet Draft Ciena
Intended status: Informational T. Marcot
Expires: January 2011 France Telecom
L. Ong
Ciena
July 12, 2010
Requirements for automatic configuration of control adjacencies
draft-roch-ccamp-reqts-auto-adj-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
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
This Internet-Draft will expire on January 12, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Roch, Marcot & Ong Expires January 12, 2011 [Page 1]
Internet-Draft draft-roch-ccamp-reqts-auto-adj July 2010
Abstract
A set of requirements and a proposed solution for the control of
hierarchical Label Switched Paths (LSPs) is found in [HIER].
However, support of multiple client layer networks and address
separation as allowed by the Automatically Switched Optical Network
(ASON) architecture [G.8080] are not covered by [HIER]. This
internet draft describes additional requirements to consider for the
use of LSP hierarchy in ASON networks.
Table of Contents
1. Introduction and Problem Statement.............................2
1.1. Separate control plane instances at different layers......3
1.2. Address and identifier separation within a layer..........3
2. Requirements...................................................4
2.1. Client Layer Identification...............................4
2.2. Routing Controller Identification.........................4
2.3. Signaling Controller Identification.......................4
2.4. Link Identification.......................................5
2.5. Requirements Summary......................................5
3. Mechanisms and Protocol Extensions.............................6
3.1. MULTI_CLIENT_LSP_TUNNEL_INTERFACE_ID Object...............6
3.2. LSP_TUNNEL_INTERFACE_ID sub-TLVs..........................7
3.2.1. Routing Controller Protocol Controller (RC PC)
Identifier..................................................7
3.2.2. Routing Controller Protocol Controller Reachable
Address.....................................................7
3.2.3. Signaling Controller Protocol Controller Identifier..7
3.2.4. Signaling Controller Protocol Controller Reachable
Address.....................................................8
4. Security Considerations........................................8
5. IANA Considerations............................................8
6. References.....................................................8
6.1. Normative References......................................8
6.2. Informative References....................................9
7. Acknowledgments................................................9
1. Introduction and Problem Statement
This problem statement applies to the operation of multilayer
networks according to the ASON architecture.
[HIER] defines a set of extensions for the control of hierarchical
Label Switched Paths (LSPs).. This internet draft describes
Roch, Marcot & Ong Expires January 12, 2011 [Page 2]
Internet-Draft draft-roch-ccamp-reqts-auto-adj July 2010
additional requirements for the use of LSP Hierarchy in ASON
networks.
1.1. Separate control plane instances at different layers
In ASON architecture, the control plane instance in a client layer
may be a separate instance than the control plane instance for the
client layer. This requires that when a server layer link is
created, sufficient information must be passed to allow a new
control (signaling and optionally routing) association to be created
between the client control instances at the ends of the new link.
This includes identification and addressing information for both the
signaling control instance and routing control instance at each end.
This draft identifies the additional requirements for ASON multi-
layer control in addition to those in [HIER].
The ASON architecture [G.8080] allows for separate control plane
instances for each controlled layer. In a real deployment, this can
be seen in a few scenarios. For example, in networks mixing legacy
equipment and emerging technologies, existing legacy control plane
for some layers and new control plane for other layers may be based
on different protocols, requiring different instances.
Additionally, some equipment may be entirely under management plane
control whereas other is under control plane. There might also be
business boundaries due to mergers and acquisitions or due to
internal company organization. In these cases, the result is
multiple instances of control plane.
Another scenario is that different instances may be used to solve
scalability problems.
1.2. Address and identifier separation within a layer
Separate identification of routing controller instances, signaling
controller instances and resource identifiers is required in order
to support ASON signaling and routing. Separation of routing
controller and resource identifier is already addressed as a
requirement in [RFC4652], as referenced by the terms "Li" and "Pi"
for the logical control plane entity and physical node identifiers,
respectively. This allows 1:n relationships between the control
entity and the physical resources being controlled, for example.
Separation of routing and signaling controller identifiers and their
respective reachable addresses allows the routing and signaling
controller identifiers to be independent of the specific network
Roch, Marcot & Ong Expires January 12, 2011 [Page 3]
Internet-Draft draft-roch-ccamp-reqts-auto-adj July 2010
address by which they are reached. This allows the operator to
modify the signaling communications network addressing scheme
without impacting the control plane protocols. Routing controller
addressing is further discussed in [RFC4258].
2. Requirements
2.1. Client Layer Identification
In order to support flexible adaptation where a server layer
provides services to multiple client layers, it is necessary to
identify to which layer the information carried in the
LSP_TUNNEL_INTERFACE_ID applies to.
New Requirement: For each client layer supported, it should be
possible to exchange both the layer identification and a separate
set of control plane identifiers associated with the client layer.
2.2. Routing Controller Identification
In ASON architecture, a routing controller possesses two
identifiers. The first is the Routing Controller Protocol Controller
Identifier (RC PC ID). The second is the IPv4 address at which the
routing controller can be reached, the Routing Controller Signaling
Control Network address (RC PC SCN address).
New requirement: Since different client layers may have different
routing controllers, it must be possible to exchange RC PC IDs and
RC PC SCN addresses for each client layer that needs to advertise
the link.
2.3. Signaling Controller Identification
In ASON architecture, signaling controller identifiers cannot be
automatically derived from routing controller identifiers. In order
to establish an RSVP-TE signaling adjacency between two client
signaling controllers, a signaling mechanism is required in the
server layer to identify the signaling controller. Each signaling
controller requires two identifiers. The first is the Signaling
Controller Protocol Controller Identifier (SC PC ID). The second is
the IPv4 address at which the signaling controller can be reached.
New Requirement: Since different client layers may have different
signaling controllers, it must be possible to exchange SC PC IDs and
SC PC SCN addresses for each client layer.
Roch, Marcot & Ong Expires January 12, 2011 [Page 4]
Internet-Draft draft-roch-ccamp-reqts-auto-adj July 2010
2.4. Link Identification
The following information is required for each link: area
identifier, node identifier and interface identifier. Optionally, a
bundle identifier may also be specified if a link is to be
advertised as part of a bundle in the client layer.
It should be noted that the node identifier is not the same as a
routing controller or signaling controller identifier. It is the
control plane identifier for the network element resources, i.e.,
the Pi identified in [RFC4652].
New requirement: Since different client layers may use different
addressing spaces to name their resources, it must be possible to
exchange separate link identification for each client layer.
2.5. Requirements Summary
The following table summarizes the information that is proposed to
be exchanged on a per client layer basis as well as coverage in
[HIER].
Per layer information Format [HIER]
--------------------- ------ ------
Area ID 32-bit Yes?
Node ID 32-bit/16-bytes Yes?
Link ID 32-bit Yes
Bundle ID 32-bit Yes
Layer Identifier TBD No
SC PC ID 32-bit/16-bytes No
SC PC SCN Address IPv4/v6 No
RC PC ID 32-bit/16-bytes No
RC PC SCN IPv4/v6 No
Roch, Marcot & Ong Expires January 12, 2011 [Page 5]
Internet-Draft draft-roch-ccamp-reqts-auto-adj July 2010
3. Mechanisms and Protocol Extensions
This section defines protocol extensions to address the requirements
described in the previous section.
3.1. MULTI_CLIENT_LSP_TUNNEL_INTERFACE_ID Object
A new MULTI_CLIENT_LSP_TUNNEL_INTERFACE_ID Object is defined for
multiple client support. The format of the object is shown below. It
supports the exchange of information for several client layers in a
single TLV.
C-NUM=193, C-Type = TBD
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ CLIENT_1_LSP_TUNNEL_INTERFACE_ID TLV ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ... ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ CLIENT_N_LSP_TUNNEL_INTERFACE_ID TLV ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each CLIENT_LSP_TUNNEL_INTERFACE_ID TVL 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 | Reserved | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Type | Switching Type| Signal Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP_TUNNEL_INTERFACE_ID TLV (without header) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: MUST be set to 0 when sending and ignored when receiving.
Type: C-Type corresponding to the format used for the
LSP_TUNNEL_INTERFACE_ID TLV as described in [HIER].
Roch, Marcot & Ong Expires January 12, 2011 [Page 6]
Internet-Draft draft-roch-ccamp-reqts-auto-adj July 2010
LSP_TUNNEL_INTERFACE_ID TLV: Format as described in 3.1.2 of [HIER],
omitting the header (length, C-NUM and C-Type).
3.2. LSP_TUNNEL_INTERFACE_ID sub-TLVs
The following sub-TLVs are optional sub-TLVs of the
LSP_TUNNEL_INTERFACE_ID, in addition to already defined Target IGP
Identifier and Component Link Identifier TLV. These sub-TLVs allow
the client layer to use separate routing and signaling controller
identifiers and reachable addresses.
3.2.1. Routing Controller Protocol Controller (RC PC) Identifier
The following sub-TLV is included to identify the RC PC associated
with the client layer. The TLV is formatted as described in Section
3.1.2 of [HIER]. The Type field has the value 3, and the Value field
has the following content:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Controller Protocol Controller Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.2. Routing Controller Protocol Controller (RC PC) Reachable Address
The following sub-TLV is included to provide the reachable address
for the RC PC associated with the client layer. The TLV is formatted
as described in Section 3.1.2 of [HIER]. The Type field has the
value 4, and the Value field has the following content:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Controller Protocol Controller Reachable IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.3. Signaling Controller Protocol Controller (SC PC) Identifier
The following sub-TLV is included to identify the SC PC associated
with the client layer. The TLV is formatted as described in Section
3.1.2 of [HIER]. The Type field has the value 5, and the Value field
has the following content:
0 1 2 3
Roch, Marcot & Ong Expires January 12, 2011 [Page 7]
Internet-Draft draft-roch-ccamp-reqts-auto-adj July 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signaling Controller Protocol Controller Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.4. Signaling Controller Protocol Controller (SC PC) Reachable
Address
The following sub-TLV is included to provide the reachable address
for the RC PC associated with the client layer. The TLV is formatted
as described in Section 3.1.2 of [HIER]. The Type field has the
value 4, and the Value field has the following content:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Controller Protocol Controller Reachable IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. Security Considerations
TBD
5. IANA Considerations
TBD
6. References
6.1. Normative References
[HIER] Shiomoto, K., and Farrel, A. (Editors), "Procedures for
Dynamically Signaled Hierarchical Label Switched Paths",
draft-ietf-ccamp-lsp-hierarchy-bis-08.txt, February 2010
[RFC4258] Brungard, D, Ed. "Requirements for Generalized Multi-
Protocol Label Switching (GMPLS) Routing for the
Automatically Switched Optical Network (ASON)", RFC4258,
November 2005
[RFC4652] Papadimitriou, D., Ed. "Evaluation of Existing Routing
Protocols against Automatic Switched Optical Network
(ASON) Routing Requirements", RFC4652, October 2006
Roch, Marcot & Ong Expires January 12, 2011 [Page 8]
Internet-Draft draft-roch-ccamp-reqts-auto-adj July 2010
6.2. Informative References
[G.8080] ITU-T Rec G.8080/Y.1304 "Architecture for the Automatically
Switched Optical Network (ASON)", June 2006
7. Acknowledgments
The authors would like to thank the following OIF member
representatives for their contribution and comments for this document:
Hans-Martin Foisel (Deutsche Telekom), George Frank (Infinera), Monica
Lazer (AT&T), Jonathan Sadler (Tellabs), Vishnu Shukla (Verizon).
Roch, Marcot & Ong Expires January 12, 2011 [Page 9]
Internet-Draft draft-roch-ccamp-reqts-auto-adj July 2010
Authors' Addresses
Evelyne Roch
Ciena
Email: eroch@ciena.com
Thierry Marcot
France Telecom
Email: thierry.marcot@orange-ftgroup.com
Lyndon Ong
Ciena
Email: lyong@ciena.com
Roch, Marcot & Ong Expires January 12, 2011 [Page 10]