- Link Availability: This represents the survivability capability
such as the protection type associated with the link.
- Diversity Support: This represents diversity information such as
the SRLG information associated with the link.
- Local Adaptation Support: This indicates the set of client layer
adaptations supported by the TCP associated with the local SNPP.
This is applicable only when the local SNP represents a TCP or can
be flexibly configured as a TCP.
Link Characteristics Capability Usage
----------------------- ---------- ---------
Signal Type REQUIRED OPTIONAL
Link Weight REQUIRED OPTIONAL
Resource Class REQUIRED OPTIONAL
Local Connection Types REQUIRED OPTIONAL
Link Capacity REQUIRED OPTIONAL
Link Availability OPTIONAL OPTIONAL
Diversity Support OPTIONAL OPTIONAL
Local Adaptation Support OPTIONAL OPTIONAL
Table 3. Link Characteristics
Note: Separate advertisements of layer-specific attributes MAY be
chosen. However, this may lead to unnecessary duplication. This can
be avoided using the inheritance property, so that the attributes
derivable from the local adaptation information do not need to be
advertised. Thus, an optimization MAY be used when several layers
are present by indicating when an attribute is inheritable from a
server layer.
4. Security Considerations
The ASON routing protocol MUST deliver the operational security
objectives where required. The overall security objectives (defined
in ITU-T Recommendation [M.3016]) of confidentiality, integrity, and
accountability may take on varying levels of importance. These
objectives do not necessarily imply requirements on the routing
protocol itself, and MAY be met by other established means.
Note: A threat analysis of a proposed routing protocol SHOULD address
masquerade, eavesdropping, unauthorized access, loss or corruption of
information (including replay attacks), repudiation, forgery, and
denial of service attacks.
5. Conclusions
The description of the ASON routing architecture and components is
provided in terms of routing functionality. This description is only
conceptual: no physical partitioning of these functions is implied.
In summary, the ASON routing architecture assumes:
- A network is subdivided into ASON RAs, which MAY support multiple
routing protocols; no one-to-one relationship SHALL be assumed.
- Routing Controllers (RCs) provide for the exchange of routing
information (primitives) for the RA. The RC is protocol
independent and MAY be realized by multiple, different protocol
controllers within an RA. The routing information exchanged
between RCs SHALL be subject to policy constraints imposed at
reference points (External- and Internal-NNI).
- In a multi-level RA hierarchy based on containment, communication
between RCs of different RAs happens only when there is a
parent/child relationship between the RAs. RCs of child RAs never
communicate with the RCs of other child RAs. There SHOULD not be
any dependencies on the different routing protocols used within a
child RA and that of its parent. The routing information
exchanged within the parent RA SHALL be independent of both the
routing protocol operating within a child RA and any control
distribution choice(s), e.g., centralized, fully distributed.
- For an RA, the set of RCs is referred to as an ASON routing
(control) domain. The routing information exchanged between
routing domains (inter-RA, i.e., inter-domain) SHALL be
independent of both the intra-domain routing protocol(s) and the
intra-domain control distribution choice(s), e.g., centralized,
fully distributed. RCs bounded to different RA levels MAY be
collocated within the same physical element or physically
distributed.
- The routing adjacency topology (i.e., the associated PC
connectivity topology) and the transport network topology SHALL
NOT be assumed to be congruent.
- The routing topology SHALL support multiple links between nodes
and RAs.
In summary, the following functionality is expected from GMPLS
routing to instantiate the ASON hierarchical routing architecture
realization (see [G.7715] and [G.7715.1]):
- RAs SHALL be uniquely identifiable within a carrier’s network,
each having a unique RA ID within the carrier’s network.
- Within an RA (one level), the routing protocol SHALL support
dissemination of hierarchical routing information (including
summarized routing information for other levels) in support of an
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 subnetwork 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 RDBs
become synchronized after a period of time.
To support hierarchical routing information dissemination within an
RA, 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 RC to RC(s) at different levels when multiple
RCs are bound to a single RA.
- A mechanism to prevent the 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.
In order to support operator-assisted changes in the containment
relationships of RAs, the routing protocol SHALL support evolution in
terms of the number of hierarchical levels of RAs. For example:
support of non-disruptive operations such as adding and removing RAs
at the top/bottom of the hierarchy, adding or removing a hierarchical
level of RAs in or from the middle of the hierarchy, as well as
aggregation and segmentation of RAs. The number of hierarchical
levels to be supported is routing protocol specific and reflects a
containment relationship; e.g., an RA insertion involves supporting a
different routing protocol domain in a portion of the network.
Reachability information (see Section 3.5.3) of the set of endpoints
reachable by a node may be advertised either as a set of UNI
Transport Resource addresses/address prefixes or a set of associated
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 an 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 collocated architecture or a physically separated
architecture may be used. A collection of links and nodes such as a
subnetwork 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.
6. Contributors
This document is the result of the CCAMP Working Group ASON Routing
Requirements design team joint effort. The following are the design
team member authors who contributed to the present document:
Wesam Alanqar (Sprint)
Deborah Brungard (ATT)
David Meyer (Cisco Systems)
Lyndon Ong (Ciena)
Dimitri Papadimitriou (Alcatel)
Jonathan Sadler (Tellabs)
Stephen Shew (Nortel)
7. Acknowledgements
The authors would like to thank Kireeti Kompella for having initiated
the proposal of an ASON Routing Requirement Design Team and the ITU-T
SG15/Q14 for their careful review and input.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
For information on the availability of the following documents,
please see http://www.itu.int:
[G.707] ITU-T Rec. G.707/Y.1322, "Network Node Interface for the
Synchronous Digital Hierarchy (SDH)", December 2003.
[G.709] ITU-T Rec. G.709/Y.1331, "Interfaces for the Optical
Transport Network (OTN)", March 2003.
[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.805] ITU-T Rec. G.805, "Generic Functional Architecture of
Transport Networks", March 2000.
[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the
Automatically Switched Optical Network (ASON)", November
2001 (and Revision, January 2003).
[M.3016] ITU-T Rec. M.3016.0, "Security for the Management Plane:
Overview", May 2005.
[T1.105] ANSI T1.105, "Synchronous Optical Network (SONET) - Basic
Description including Multiplex Structure, Rates, and
Formats", 2001.
Appendix 1: ASON Terminology
This document makes use of the following terms:
Administrative domain (see Recommendation [G.805]): For the purposes
of [G.7715.1], an administrative domain represents the extent of
resources that 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.
Adaptation function (see Recommendation [G.805]): A "transport
processing function" that processes the client layer information for
transfer over a server layer trail.
Client/Server relationship: The association between layer networks
that is performed by an "adaptation" function to allow the link
connection in the client layer network to be supported by a trail in
the server layer network.
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" that
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 that 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.
Multiplexing (see Recommendation [G.805]): Multiplexing techniques
are used to combine client layer signals. The many-to-one
relationship represents the case of several link connections of
client layer networks supported by one server layer trail at the same
time.
Subnetwork Point (SNP): The SNP is a control plane abstraction that
represents an actual or potential transport plane resource. SNPs (in
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.
Trail (see Recommendation [G.805]): A "transport entity" that
consists of an associated pair of "unidirectional trails" capable of
simultaneously transferring information in opposite directions
between their respective inputs and outputs.
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 the [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.
Variable adaptation function: A single server layer trail may
dynamically support different multiplexing structures, i.e., link
connections for multiple client layer networks.
Appendix 2: ASON Routing Terminology
This document makes use of the following terms:
Routing Area (RA): An 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], an RA is defined by
a set of subnetworks, the links that interconnect them, and the
interfaces representing the ends of the links exiting that RA. An RA
may contain smaller RAs inter-connected by links. The limit of
subdivision results in an RA that contains two subnetworks
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
Traffic Engineering (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.
Authors’ Addresses
Wesam Alanqar
Sprint
EMail: wesam.alanqar@mail.sprint.com
Deborah Brungard, Ed.
AT&T
Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA
Phone: +1 732 4201573
EMail: dbrungard@att.com
David Meyer
Cisco Systems
EMail: dmm@1-4-5.net
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
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.
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 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.