One document matched: draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt
CCAMP Working Group John Drake (Calient)
Internet Draft Chris Hopps (Procket)
Category: Informational Lyndon Ong (Ciena)
Dimitri Papadimitriou (Alcatel)
Expiration Date: July 2005 Jonathan Sadler (Tellabs)
Stephen Shew (Nortel)
Dave Ward (Cisco)
January 2005
Evaluation of existing Routing Protocols
against ASON routing requirements
draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with RFC 3668.
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 (2004). All Rights Reserved.
Abstract
The Generalized MPLS (GMPLS) suite of protocols has been defined to
control different switching technologies as well as different
applications. These include support for requesting TDM connections
including SONET/SDH and Optical Transport Networks (OTNs).
J.Drake et al. - Expires January 2005 1
draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt January 2005
This document provides an evaluation of the IETF Routing Protocols
against the routing requirements for an Automatically Switched
Optical Network (ASON) as defined by ITU-T.
1. Contributors
This document is the result of the CCAMP Working Group ASON Routing
Solution design team joint effort.
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 [RFC2119].
3. Introduction
There are certain capabilities that are needed to support the ITU-T
Automatically Switched Optical Network (ASON) control plane
architecture as defined in [G.8080].
[ASON-RR] details the routing requirements for the GMPLS routing
suite of protocols to support the capabilities and functionality of
ASON control planes identified in [G.7715] and in [G.7715.1]. The
ASON routing architecture provides for a conceptual reference
architecture, with definition of functional components and common
information elements to enable end-to-end routing in the case of
protocol heterogeneity and facilitate management of ASON networks.
This description is only conceptual: no physical partitioning of
these functions is implied.
However, [ASON-RR] does not address GMPLS routing protocol
applicability or capabilities. This document evaluates the IETF
Routing Protocols against the requirements identified in [ASON-RR].
The result of this evaluation is detailed in Section 5. Close
examination of applicability scenarios and the result of the
evaluation of these scenarios are provided in Section 6.
ASON (Routing) terminology sections are provided in Appendix 1 and 2.
4. Requirements - Overview
The following functionality is expected from GMPLS routing protocol
to instantiate the ASON hierarchical routing architecture realization
(see [G.7715] and [G.7715.1]):
- Routing Areas (RAs) shall be uniquely identifiable within a
carrier's network, each having a unique RA Identifier (RA ID)
within the carrier's network.
- Within a RA (one level), the routing protocol shall support
dissemination of hierarchical routing information (including
summarized routing information for other levels) in support of an
J.Drake et al. - Expires July 2005 2
draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt January 2005
architecture of multiple hierarchical levels of RAs; the number of
hierarchical RA levels to be supported by a routing protocol is
implementation specific.
- The routing protocol shall support routing information based on a
common set of information elements as defined in [G.7715] and
[G.7715.1], divided between attributes pertaining to links and
abstract nodes (each representing either a sub-network or simply a
node). [G.7715] recognizes that the manner in which the routing
information is represented and exchanged will vary with the
routing protocol used.
- The routing protocol shall converge such that the distributed
Routing DataBases (RDB) become synchronized after a period of
time.
To support dissemination of hierarchical routing information, the
routing protocol must deliver:
- Processing of routing information exchanged between adjacent
levels of the hierarchy (i.e. Level N+1 and N) including
reachability and upon policy decision summarized topology
information.
- Self-consistent information at the receiving level resulting from
any transformation (filter, summarize, etc.) and forwarding of
information from one Routing Controller (RC) to RC(s) at different
levels when multiple RCs bound to a single RA.
- A mechanism to prevent re-introduction of information propagated
into the Level N RA's RC back to the adjacent level RA's RC from
which this information has been initially received.
Note: the number of hierarchical levels to be supported is routing
protocol specific and reflects a containment relationship.
Reachability information may be advertised either as a set of UNI
Transport Resource address prefixes, or a set of associated
Subnetwork Point Pool (SNPP) link IDs/SNPP link ID prefixes, assigned
and selected consistently in their applicability scope. The formats
of the control plane identifiers in a protocol realization are
implementation specific. Use of a routing protocol within a RA should
not restrict the choice of routing protocols for use in other RAs
(child or parent).
As ASON does not restrict the control plane architecture choice used,
either a co-located architecture or a physically separated
architecture may be used. A collection of links and nodes such as a
sub-network or RA must be able to represent itself to the wider
network as a single logical entity with only its external links
visible to the topology database.
5. Evaluation
This section evaluates support of existing IETF routing protocols
with respect to the requirements summarized from [ASON-RR] in Section
J.Drake et al. - Expires July 2005 3
draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt January 2005
4. Candidate routing protocols are IGP (OSPF and IS-IS) and BGP. The
latter in not addressed in the current version of this document.
5.1 Terminology and Identification
- Pi is a physical node (bearer/data/transport plane) node
- Li is a logical control plane identifier that is associated to a
single data plane (abstract) node
Li = logical node id or "TE router id" i.e. for
. RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA
. RFC 3784: Traffic Engineering Router ID TLV (Type 134)
- Ri is a control plane "router" e.g. (advertising) Router_ID i.e.
. RFC 2328: Router ID (32-bit)
. RFC 1195: IS-IS System ID (48-bit)
The Router_ID (represented by Ri) does not enter into the
identification of the logical entities representing the data plane
resources such as links. The Routing DataBase (RDB) is associated to
the Ri.
Aside from the Li/Pi mappings, these identifiers are not assumed to
be in a particular entity relationship, e.g., an Ri may have
multiple Li in its scope.
Note: Si is a control plane signaling function associated with one
or more Li.
5.2 RA Identification
TBD
5.3 Routing Information Exchange
We focus on routing information exchange between Ri entities
(through routing adjacencies) within single hierarchical level.
Routing information mapping between levels may require specific
guidelines.
The control plane does not transport Pi information as these are
data plane addresses for which the Li/Pi mapping is kept (link)
local - see for instance the transport LMP document [LMP-T] where
such exchange is described. Example: the transport plane identifier
is the Pi (the identifier assigned to the physical element) be for
instance "666B.F999.AF10.222C", the control plane identifier is the
Li (the identifier assigned by the control plane), be for instance
"1.1.1.1".
The control plane exchanges the control plane identifier information
but not the transport plane identifier information (i.e. not
"666B.F999.AF10.222C" but only "1.1.1.1"). The mapping Li/Pi is kept
local. So, when the Si receives a control plane message requesting
the use of "1.1.1.1", Si knows locally that this information refers
J.Drake et al. - Expires July 2005 4
draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt January 2005
to the data plane entity identified by the transport plane
identifier "666B.F999.AF10.222C".
The control plane carries:
1) its view of the data plane link end-points and other link
connection end-points
2) the identifiers scoped by the Li's i.e. referred to as an
associated IPv4/IPv6 addressing space;
5.2.1 Link Attributes
From the list of link attributes and characteristics (detailed in
[ASON-RR], the Local Adaptation support information is missing as TE
link attribute. GMPLS routing does not currently consider the use of
dedicated TE link attribute(s) to describe the cross/inter-layer
relationships. All other TE link attributes and characteristics are
currently covered.
However, the representation of bandwidth requires further analysis
i.e. GMPLS Routing defines an Interface Switching Capability
Descriptor (ISCD) that delivers information about the (maximum/
minimum) bandwidth per priority an LSP can make use of. In the ASON
context, other representations are possible, e.g., in terms of a set
of tuples <signal_type; number of unallocated timeslots>. The latter
also may require definition of additional signal types (from those
defined in [RFC 3496]) to represent contiguous concatenation i.e.
STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256.
The method proposed in [GMPLS-RTG] is the most straightforward
without requiring any bandwidth accounting change from an LSR
perspective. However, it introduces some lost of information. This
lost of information affects the number of signals that can be used
but not the range they cover. On the other hand, if additional
technology specific information (such as capabilities) are
advertised a finer grained resource countdown and accounting can be
performed allowing for network wide resource allocation in Sonet/SDH
environments.
5.2.2 Node Attributes
Nodes attributes include the "Logical Node ID" (as detailed in
Section 6.1) and the reachability information as described in
Section 6.2.3.
5.2.3 Reachability Information
Advertisement of reachability can be achieved using the techniques
described in [OSPF-NODE] where the set of local addresses are
carried in a OSPF TE LSA node attribute TLV (a specific sub-TLV is
defined per address family, e.g., IPv4 and IPv6).
J.Drake et al. - Expires July 2005 5
draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt January 2005
A similar mechanism does not exist for IS-IS as the Extended IP
Reachability TLV [RFC3784] focuses on IP reachable end-points
(terminating points), as its name indicates.
In order to advertise blocks of reachable address prefixes a
summarization mechanism is additionally required. This mechanism may
take the form of an prefix length (that indicates the number of
significant bits in the prefix) or a network mask.
5.3 Routing Information Abstraction
TBD
5.4 Dissemination of routing information in support of multiple
hierarchical levels of RAs
TBD
5.6 Routing Protocol Convergence
Link state protocols have been designed to detect topological
changes (such as interface failures, link attributes modification).
Convergence period is short and involves a minimum of routing
information exchange.
Therefore, existing routing protocol convergence mechanisms are
sufficient for ASON applications.
6. Evaluation Scenarios
The evaluation scenarios are the following: referred to as
respectively case 1), 2), 3) and 4). Additional base scenarios
(being not combinations or decomposition of entities) may further
complete this set in a future revision of this document.
In the below Figure 1:
- R3 represents an LSR with all components collocated.
- R2 shows how the "router" component may be disjoint from the node
- R1 shows how a single "router" may manage multiple nodes
------------------- -------
|R1 | |R2 |
| | | | ------
| L1 L2 L3 | | L4 | |R3 |
| : : : | | : | | |
| : : : | | : | | L5 |
Control ---+-----+-----+--- ---+--- | : |
Plane : : : : | : |
----------------+-----+-----+-----------+-------+---+--+-
Data : : : : | : |
Plane -- : -- -- | -- |
----|P1|--------|P3|--------|P4|------+-|P5|-+-
J.Drake et al. - Expires July 2005 6
draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt January 2005
-- \ : / -- -- | -- |
\ -- / | |
|P2| ------
--
Case 1) as represented refers either to direct links between edges
or "logical links" as per below figure (or any combination of them)
------ ------
| | | |
| L1 | | L2 |
| : | | : |
| : R1| | : R2|
Control Plane --+--- --+---
Elements : :
------------------+-----------------------------+------------------
Data Plane : :
Elements : :
----+-----------------------------+-----
| : : |
| --- --- --- |
| | |----------| P |----------| | |
---+--| | --- | |---+---
| | | | | |
| | P1|-------------------------| P2| |
| --- --- |
----------------------------------------
Another case (referred to as Case 4) is constituted by the Abstract
Node as represented in the below figure. There is no internal
structure associated (externally) to the abstract node.
--------------
|R4 |
| |
| L6 |
| : |
| ...... |
---:------:---
Control Plane : :
+------+------+------+
Data Plane : :
---:------:---
|P8 : : |
| -- -- |
--+-|P |----|P |-+--
| -- -- |
--------------
Note: the "signaling function" i.e. the control plane entity that
processes the signaling messages (referred to as Si) is not
represented in these Figures. More than one Si can be associated to
J.Drake et al. - Expires July 2005 7
draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt January 2005
one Ri (N:1 relationship, N >= 1) and make use of the path
computation function associated to the Ri.
7. Acknowledgements
The authors would like to thank Adrian Farrel for having initiated
the proposal of an ASON Routing Solution Design Team and the ITU-T
SG15/Q14 for their careful review and input.
8. References
8.1 Normative References
[GMPLS-RTG] Kompella, K. (Editor) et al., "Routing Extensions in
Support of Generalized MPLS," Internet Draft (work in
progress), draft-ietf-ccamp-gmpls-routing-09.txt,
October 2003.
[LMP-T] D.Fedyk et al., "A Transport Network View of LMP,"
Internet Draft (work in progress), draft-ietf-ccamp-
transport-lmp-00.txt, September 2004.
[OSPF-NODE] Aggarwal, R. and Kompella, K., "Advertising a Router's
Local Addresses in OSPF TE Extensions," Internet Draft,
(work in progress), draft-ietf-ospf-te-node-addr-
01.txt, July 2004.
[RFC2026] S.Bradner, "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2328] J.Moy, "OSPF Version 2", RFC 2328, April 1998.
[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3630] D.Katz et al. "Traffic Engineering (TE) Extensions to
OSPF Version 2", RFC 3630, September 2003.
[RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
[RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
[RFC3784] H.Smit and T.Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE),"
RFC 3784, June 2004.
[RFC3946] Mannie, E. and Papadimitriou, D. (Editors) et al.,
"Generalized Multi-Protocol Label Switching Extensions
for SONET and SDH Control," RFC 3946, October 2004.
J.Drake et al. - Expires July 2005 8
draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt January 2005
8.2 Informative References
[ASON-RR] W.Alanqar et al. "Requirements for Generalized MPLS
(GMPLS) Routing for Automatically Switched Optical
Network (ASON)," Work in progress, draft-ietf-ccamp-
gmpls-ason-routing-reqts-04.txt, May 2004.
For information on the availability of ITU Documents, please see
http://www.itu.int
[G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and
Requirements for the Automatically Switched Optical
Network (ASON)," June 2002.
[G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing
Architecture and Requirements for Link State Protocols,"
November 2003.
[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the
Automatically Switched Optical Network (ASON),"
November 2001 (and Revision, January 2003).
9. Author's Addresses (to be completed)
Lyndon Ong (Ciena Corporation)
5965 Silver Creek Valley Rd,
San Jose, CA 95128, USA
Phone: +1 408 8347894
EMail: lyong@ciena.com
Dimitri Papadimitriou (Alcatel)
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 2408491
EMail: dimitri.papadimitriou@alcatel.be
Jonathan Sadler
1415 W. Diehl Rd
Naperville, IL 60563
EMail: jonathan.sadler@tellabs.com
Stephen Shew (Nortel Networks)
PO Box 3511 Station C
Ottawa, Ontario, CANADA K1Y 4H7
Phone: +1 613 7632462
EMail: sdshew@nortelnetworks.com
J.Drake et al. - Expires July 2005 9
draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt January 2005
Appendix 1: ASON Terminology
This document makes use of the following terms:
Administrative domain: (see Recommendation G.805) for the purposes of
[G7715.1] an administrative domain represents the extent of resources
which belong to a single player such as a network operator, a service
provider, or an end-user. Administrative domains of different players
do not overlap amongst themselves.
Control plane: performs the call control and connection control
functions. Through signaling, the control plane sets up and releases
connections, and may restore a connection in case of a failure.
(Control) Domain: represents a collection of (control) entities that
are grouped for a particular purpose. The control plane is subdivided
into domains matching administrative domains. Within an
administrative domain, further subdivisions of the control plane are
recursively applied. A routing control domain is an abstract entity
that hides the details of the RC distribution.
External NNI (E-NNI): interfaces are located between protocol
controllers between control domains.
Internal NNI (I-NNI): interfaces are located between protocol
controllers within control domains.
Link: (see Recommendation G.805) a "topological component" which
describes a fixed relationship between a "subnetwork" or "access
group" and another "subnetwork" or "access group". Links are not
limited to being provided by a single server trail.
Management plane: performs management functions for the Transport
Plane, the control plane and the system as a whole. It also provides
coordination between all the planes. The following management
functional areas are performed in the management plane: performance,
fault, configuration, accounting and security management
Management domain: (see Recommendation G.805) a management domain
defines a collection of managed objects which are grouped to meet
organizational requirements according to geography, technology,
policy or other structure, and for a number of functional areas such
as configuration, security, (FCAPS), for the purpose of providing
control in a consistent manner. Management domains can be disjoint,
contained or overlapping. As such the resources within an
administrative domain can be distributed into several possible
overlapping management domains. The same resource can therefore
belong to several management domains simultaneously, but a management
domain shall not cross the border of an administrative domain.
Subnetwork Point (SNP): The SNP is a control plane abstraction that
represents an actual or potential transport plane resource. SNPs (in
J.Drake et al. - Expires July 2005 10
draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt January 2005
different subnetwork partitions) may represent the same transport
resource. A one-to-one correspondence should not be assumed.
Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together
for the purposes of routing.
Termination Connection Point (TCP): A TCP represents the output of a
Trail Termination function or the input to a Trail Termination Sink
function.
Transport plane: provides bi-directional or unidirectional transfer
of user information, from one location to another. It can also
provide transfer of some control and network management information.
The Transport Plane is layered; it is equivalent to the Transport
Network defined in G.805 Recommendation.
User Network Interface (UNI): interfaces are located between protocol
controllers between a user and a control domain. Note: there is no
routing function associated with a UNI reference point.
J.Drake et al. - Expires July 2005 11
draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt January 2005
Appendix 2: ASON Routing Terminology
This document makes use of the following terms:
Routing Area (RA): a RA represents a partition of the data plane and
its identifier is used within the control plane as the representation
of this partition. Per [G.8080] a RA is defined by a set of sub-
networks, the links that interconnect them, and the interfaces
representing the ends of the links exiting that RA. A RA may contain
smaller RAs inter-connected by links. The limit of subdivision
results in a RA that contains two sub-networks interconnected by a
single link.
Routing Database (RDB): repository for the local topology, network
topology, reachability, and other routing information that is updated
as part of the routing information exchange and may additionally
contain information that is configured. The RDB may contain routing
information for more than one Routing Area (RA).
Routing Components: ASON routing architecture functions. These
functions can be classified as protocol independent (Link Resource
Manager or LRM, Routing Controller or RC) and protocol specific
(Protocol Controller or PC).
Routing Controller (RC): handles (abstract) information needed for
routing and the routing information exchange with peering RCs by
operating on the RDB. The RC has access to a view of the RDB. The RC
is protocol independent.
Note: Since the RDB may contain routing information pertaining to
multiple RAs (and possibly to multiple layer networks), the RCs
accessing the RDB may share the routing information.
Link Resource Manager (LRM): supplies all the relevant component and
TE link information to the RC. It informs the RC about any state
changes of the link resources it controls.
Protocol Controller (PC): handles protocol specific message exchanges
according to the reference point over which the information is
exchanged (e.g. E-NNI, I-NNI), and internal exchanges with the RC.
The PC function is protocol dependent.
J.Drake et al. - Expires July 2005 12
draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt January 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
J.Drake et al. - Expires July 2005 13
| PAFTECH AB 2003-2026 | 2026-04-23 10:43:48 |