doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc4258.txt b/doc/rfc/rfc4258.txt
new file mode 100644
index 0000000..3bc2dbb
--- /dev/null
+++ b/doc/rfc/rfc4258.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                   D. Brungard, Ed.
+Request for Comments: 4258                                           ATT
+Category: Informational                                    November 2005
+
+
+  Requirements for Generalized Multi-Protocol Label Switching (GMPLS)
+     Routing for the Automatically Switched Optical Network (ASON)
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The Generalized Multi-Protocol Label Switching (GMPLS) suite of
+   protocols has been defined to control different switching
+   technologies as well as different applications.  These include
+   support for requesting Time Division Multiplexing (TDM) connections
+   including Synchronous Optical Network (SONET)/Synchronous Digital
+   Hierarchy (SDH) and Optical Transport Networks (OTNs).
+
+   This document concentrates on the routing requirements placed on the
+   GMPLS suite of protocols in order to support the capabilities and
+   functionalities of an Automatically Switched Optical Network (ASON)
+   as defined by the ITU-T.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brungard, Ed.                Informational                      [Page 1]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions Used in This Document ...............................4
+   3. ASON Routing Architecture and Requirements ......................4
+      3.1. Multiple Hierarchical Levels of ASON Routing Areas (RAs) ...5
+      3.2. Hierarchical Routing Information Dissemination .............6
+      3.3. Configuration ..............................................8
+           3.3.1. Configuring the Multi-Level Hierarchy ...............8
+           3.3.2. Configuring RC Adjacencies ..........................8
+      3.4. Evolution ..................................................8
+      3.5. Routing Attributes .........................................8
+           3.5.1. Taxonomy of Routing Attributes ......................9
+           3.5.2. Commonly Advertised Information .....................9
+           3.5.3. Node Attributes ....................................10
+           3.5.4. Link Attributes ....................................11
+   4. Security Considerations ........................................12
+   5. Conclusions ....................................................12
+   6. Contributors ...................................................15
+   7. Acknowledgements ...............................................15
+   8. References .....................................................16
+      8.1. Normative References ......................................16
+      8.2. Informative References ....................................16
+
+1.  Introduction
+
+   The Generalized Multi-Protocol Label Switching (GMPLS) suite of
+   protocols provides, among other capabilities, support for controlling
+   different switching technologies.  These include support for
+   requesting TDM connections utilizing SONET/SDH (see [T1.105] and
+   [G.707], respectively) as well as Optical Transport Networks (OTNs,
+   see [G.709]).  However, there are certain capabilities that are
+   needed to support the ITU-T G.8080 control plane architecture for an
+   Automatically Switched Optical Network (ASON).  Therefore, it is
+   desirable to understand the corresponding requirements for the GMPLS
+   protocol suite.  The ASON control plane architecture is defined in
+   [G.8080]; ASON routing requirements are identified in [G.7715] and in
+   [G.7715.1] for ASON link state protocols.  These Recommendations
+   apply to all [G.805] layer networks (e.g., SDH and OTN), and provide
+   protocol-neutral functional requirements and architecture.
+
+   This document focuses on the routing requirements for the GMPLS suite
+   of protocols to support the capabilities and functionality of ASON
+   control planes.  This document summarizes the ASON requirements using
+   ASON terminology.  This document does not address GMPLS applicability
+   or GMPLS capabilities.  Any protocol (in particular, routing)
+
+
+
+
+
+Brungard, Ed.                Informational                      [Page 2]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+   applicability, design, or suggested extensions are strictly outside
+   the scope of this document.  ASON (Routing) terminology sections are
+   provided in Appendixes 1 and 2.
+
+   The ASON routing architecture is based on the following assumptions:
+
+   -  A network is subdivided based on operator decision and criteria
+      (e.g., geography, administration, and/or technology); the network
+      subdivisions are defined in ASON as Routing Areas (RAs).
+
+   -  The routing architecture and protocols applied after the network
+      is subdivided are an operator's choice.  A multi-level hierarchy
+      of RAs, as defined in ITU-T [G.7715] and [G.7715.1], provides for
+      a hierarchical relationship of RAs based on containment; i.e.,
+      child RAs are always contained within a parent RA.  The
+      hierarchical containment relationship of RAs provides for routing
+      information abstraction, thereby enabling scalable routing
+      information representation.  The maximum number of hierarchical RA
+      levels to be supported is not specified (outside the scope of this
+      document).
+
+   -  Within an ASON RA and for each level of the routing hierarchy,
+      multiple routing paradigms (hierarchical, step-by-step, source-
+      based), centralized or distributed path computation, and multiple
+      different routing protocols MAY be supported.  The architecture
+      does not assume a one-to-one correspondence between a routing
+      protocol and an RA level, and allows the routing protocol(s) used
+      within different RAs (including child and parent RAs) to be
+      different.  The realization of the routing paradigm(s) to support
+      the hierarchical levels of RAs is not specified.
+
+   -  The routing adjacency topology (i.e., the associated Protocol
+      Controller (PC) connectivity) and transport topology are NOT
+      assumed to be congruent.
+
+   -  The requirements support architectural evolution, e.g., a change
+      in the number of RA levels, as well as aggregation and
+      segmentation of RAs.
+
+   The description of 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.
+
+
+
+
+
+
+Brungard, Ed.                Informational                      [Page 3]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+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].
+
+   Although [RFC2119] describes interpretations of these key words in
+   terms of protocol specifications and implementations, they are used
+   in this document to describe design requirements for protocol
+   extensions.
+
+3.  ASON Routing Architecture and Requirements
+
+   The fundamental architectural concept is the RA and its related
+   functional components (see Appendix 2 on terminology).  The routing
+   services offered by an RA are provided by a Routing Performer (RP).
+   An RP is responsible for a single RA, and it MAY be functionally
+   realized using distributed Routing Controllers (RCs).  The RC,
+   itself, MAY be implemented as a cluster of distributed entities (ASON
+   refers to the cluster as a Routing Control Domain (RCD)).  The RC
+   components for an RA receive routing topology information from their
+   associated Link Resource Manager(s) (LRMs) and store this information
+   in the Routing Information Database (RDB).  The RDB is replicated at
+   each RC bounded to the same RA, and MAY contain information about
+   multiple transport plane network layers.  Whenever the routing
+   topology changes, the LRM informs the corresponding RC, which in turn
+   updates its associated RDB.  In order to ensure RDB synchronization,
+   the RCs cooperate and exchange routing information.  Path computation
+   functions MAY exist in each RC, MAY exist on selected RCs within the
+   same RA, or MAY be centralized for the RA.
+
+
+   In this context, communication between RCs within the same RA is
+   realized using a particular routing protocol (or multiple protocols).
+   In ASON, the communication component is represented by the protocol
+   controller (PC) component(s) and the protocol messages are conveyed
+   over the ASON control plane's Signaling Control Network (SCN).  The
+   PC MAY convey information for one or more transport network layers
+   (refer to the note in Section 3.2).  The RC is protocol independent,
+   and RC communications MAY be realized by multiple, different PCs
+   within an RA.
+
+   The ASON routing architecture defines a multi-level routing hierarchy
+   of RAs based on a containment model to support routing information
+   abstraction.  [G.7715.1] defines the ASON hierarchical link state
+   routing protocol requirements for communication of routing
+   information within an RA (one level) to support hierarchical routing
+   information dissemination (including summarized routing information
+
+
+
+Brungard, Ed.                Informational                      [Page 4]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+   for other levels).  The communication between any of the other
+   functional component(s) (e.g., SCN, LRM, and between RCDs (RC-RC
+   communication between RAs)) is outside the scope of [G.7715.1]
+   protocol requirements and, thus, is also outside the scope of this
+   document.
+
+   ASON routing components are identified by identifiers that are drawn
+   from different name spaces (see [G.7715.1]).  These are control plane
+   identifiers for transport resources, components, and SCN addresses.
+   The formats of those identifiers in a routing protocol realization
+   SHALL be implementation specific and outside the scope of this
+   document.
+
+   The failure of an RC, or the failure of communications between RCs,
+   and the subsequent recovery from the failure condition MUST NOT
+   disrupt calls in progress (i.e., already established) and their
+   associated connections.  Calls being set up MAY fail to complete, and
+   the call setup service MAY be unavailable during recovery actions.
+
+3.1.  Multiple Hierarchical Levels of ASON Routing Areas (RAs)
+
+   [G.8080] introduces the concept of a Routing Area (RA) in reference
+   to a network subdivision.  RAs provide for routing information
+   abstraction.  Except for the single RA case, RAs are hierarchically
+   contained: a higher-level (parent) RA contains lower-level (child)
+   RAs that in turn MAY also contain RAs, etc.  Thus, RAs contain RAs
+   that recursively define successive hierarchical RA levels.
+
+   However, the RA containment relationship describes only an
+   architectural hierarchical organization of RAs.  It does not restrict
+   a specific routing protocol's realization (e.g., OSPF multi-areas,
+   path computation, etc.).  Moreover, the realization of the routing
+   paradigm to support a hierarchical organization of RAs and the number
+   of hierarchical RA levels to be supported is routing protocol
+   specific and outside the scope of this document.
+
+   In a multi-level hierarchy of RAs, it is necessary to distinguish
+   among RCs for the different levels of the RA hierarchy.  Before any
+   pair of RCs establishes communication, they MUST verify that they are
+   bound to the same parent RA (see Section 3.2).  An RA identifier (RA
+   ID) is required to provide the scope within which the RCs can
+   communicate.  To distinguish between RCs bound to the same RA, an RC
+   identifier (RC ID) is required; the RC ID MUST be unique within its
+   containing RA.
+
+   An RA represents a partition of the data plane, and its identifier
+   (i.e., RA ID) is used within the control plane as a reference to the
+   data plane partition.  Each RA within a carrier's network SHALL be
+
+
+
+Brungard, Ed.                Informational                      [Page 5]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+   uniquely identifiable.  RA IDs MAY be associated with a transport
+   plane name space, whereas RC IDs are associated with a control plane
+   name space.
+
+3.2.  Hierarchical Routing Information Dissemination
+
+   Routing information can be exchanged between RCs bound to adjacent
+   levels of the RA hierarchy, i.e., Level N+1 and N, where Level N
+   represents the RAs contained by Level N+1.  The links connecting RAs
+   may be viewed as external links (inter-RA links), and the links
+   representing connectivity within an RA may be viewed as internal
+   links (intra-RA links).  The external links to an RA at one level of
+   the hierarchy may be internal links in the parent RA.  Intra-RA links
+   of a child RA MAY be hidden from the parent RA's view.
+
+   The physical location of RCs for adjacent RA levels, their
+   relationship, and their communication protocol(s) are outside the
+   scope of this document.  No assumption is made regarding how RCs
+   communicate between adjacent RA levels.  If routing information is
+   exchanged between an RC, its parent, and its child RCs, it SHOULD
+   include reachability (see Section 3.5.3) and MAY include, upon policy
+   decision, node and link topology.  Communication between RAs only
+   takes place between RCs with a parent/child relationship.  RCs of one
+   RA never communicate with RCs of another RA at the same level.  There
+   SHOULD not be any dependencies on the different routing protocols
+   used within an RA or in different RAs.
+
+   Multiple RCs bound to the same RA MAY transform (filter, summarize,
+   etc.) and then forward information to RCs at different levels.
+   However, in this case, the resulting information at the receiving
+   level must be self-consistent (i.e., ensure consistency between
+   transform operations performed on routing information at different
+   levels to ensure proper information processing).  This MAY be
+   achieved using a number of mechanisms.
+
+   Note: There is no implied relationship between multi-layer transport
+   networks and multi-level routing.  Implementations MAY support a
+   hierarchical routing topology (multi-level) with a single routing
+   protocol instance for multiple transport switching layers or a
+   hierarchical routing topology for one transport switching layer.
+
+   1. Type of Information Exchanged
+
+      The type of information flowing upward (i.e., Level N to Level
+      N+1) and the information flowing downward (i.e., Level N+1 to
+      Level N) are used for similar purposes, namely, the exchange of
+      reachability information and summarized topology information to
+
+
+
+
+Brungard, Ed.                Informational                      [Page 6]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+      allow routing across multiple RAs.  The summarization of topology
+      information may impact the accuracy of routing and may require
+      additional path calculation.
+
+      The following information exchanges are expected:
+
+      -  Level N+1 visibility to Level N reachability and topology (or
+         upward information communication) allowing RC(s) at Level N+1
+         to determine the reachable endpoints from Level N.
+
+      -  Level N visibility to Level N+1 reachability and topology (or
+         downward information communication) allowing RC(s) bounded to
+         an RA at Level N to develop paths to reachable endpoints
+         outside of the RA.
+
+   2. Interactions between Upward and Downward Communication
+
+      When both upward and downward information exchanges contain
+      endpoint reachability information, a feedback loop could
+      potentially be created.  Consequently, the routing protocol MUST
+      include a method to:
+
+      -  prevent information propagated from a Level N+1 RA's RC into
+         the Level N RA's RC from being re-introduced into the Level N+1
+         RA's RC, and
+
+      -  prevent information propagated from a Level N-1 RA's RC into
+         the Level N RA's RC from being re-introduced into the Level N-1
+         RA's RC.
+
+      The routing protocol SHALL differentiate the routing information
+      originated at a given-level RA from derived routing information
+      (received from external RAs), even when this information is
+      forwarded by another RC at the same level.  This is a necessary
+      condition to be fulfilled by routing protocols to be loop free.
+
+   3. Method of Communication
+
+      Two approaches exist for communication between Level N and N+1:
+
+      -  The first approach places an instance of a Level N routing
+         function and an instance of a Level N+1 routing function in the
+         same system.  The communications interface is within a single
+         system and is thus not an open interface subject to
+         standardization.  However, information re-advertisement or
+         leaking MUST be performed in a consistent manner to ensure
+         interoperability and basic routing protocol correctness (e.g.,
+         cost/metric value).
+
+
+
+Brungard, Ed.                Informational                      [Page 7]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+      -  The second approach places the Level N routing function on a
+         separate system from the Level N+1 routing function.  In this
+         case, a communication interface must be used between the
+         systems containing the routing functions for different levels.
+         This communication interface and mechanisms are outside the
+         scope of this document.
+
+3.3.  Configuration
+
+3.3.1.  Configuring the Multi-Level Hierarchy
+
+   The RC MUST support static (i.e., operator assisted) and MAY support
+   automated configuration of the information describing its
+   relationship to its parent and its child within the hierarchical
+   structure (including RA ID and RC ID).  When applied recursively, the
+   whole hierarchy is thus configured.
+
+3.3.2.  Configuring RC Adjacencies
+
+   The RC MUST support static (i.e., operator assisted) and MAY support
+   automated configuration of the information describing its associated
+   adjacencies to other RCs within an RA.  The routing protocol SHOULD
+   support all the types of RC adjacencies described in Section 9 of
+   [G.7715].  The latter includes congruent topology (with distributed
+   RC) and hubbed topology (e.g., note that the latter does not
+   automatically imply a designated RC).
+
+3.4.  Evolution
+
+   The containment relationships of RAs may change, motivated by events
+   such as mergers, acquisitions, and divestitures.
+
+   The routing protocol SHOULD be capable of supporting architectural
+   evolution in terms of the number of hierarchical levels of RAs, as
+   well as the aggregation and segmentation of RAs.  RA ID uniqueness
+   within an administrative domain may facilitate these operations.  The
+   routing protocol is not expected to automatically initiate and/or
+   execute these operations.  Reconfiguration of the RA hierarchy may
+   not disrupt calls in progress, though calls being set up may fail to
+   complete, and the call setup service may be unavailable during
+   reconfiguration actions.
+
+3.5.  Routing Attributes
+
+   Routing for transport networks is performed on a per-layer basis,
+   where the routing paradigms MAY differ among layers and within a
+   layer.  Not all equipment supports the same set of transport layers
+   or the same degree of connection flexibility at any given layer.  A
+
+
+
+Brungard, Ed.                Informational                      [Page 8]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+   server layer trail may support various clients, involving different
+   adaptation functions.  In addition, equipment may support variable
+   adaptation functionality, whereby a single server layer trail
+   dynamically supports different multiplexing structures.  As a result,
+   routing information MAY include layer-specific, layer-independent,
+   and client/server adaptation information.
+
+3.5.1.  Taxonomy of Routing Attributes
+
+   Attributes can be organized according to the following categories:
+
+   -  Node related or link related
+
+   -  Provisioned, negotiated, or automatically configured
+
+   -  Inherited or layer specific (client layers can inherit some
+      attributes from the server layer, while other attributes such as
+      Link Capacity are specified by layer)
+
+   (Component) link attributes MAY be statically or automatically
+   configured for each transport network layer.  This may lead to
+   unnecessary repetition.  Hence, the inheritance property of
+   attributes MAY also be used to optimize the configuration process.
+
+   ASON uses the term SubNetwork Point (SNP) for the control plane
+   representation of a transport plane resource.  The control plane
+   representation and transport plane topology are NOT assumed to be
+   congruent; the control plane representation SHALL not be restricted
+   by the physical topology.  The relational grouping of SNPs for
+   routing is termed an SNP Pool (SNPP).  The routing function
+   understands topology in terms of SNPP links.  Grouping MAY be based
+   on different link attributes (e.g., SRLG information, link weight,
+   etc).
+
+   Two RAs may be linked by one or more SNPP links.  Multiple SNPP links
+   may be required when component links are not equivalent for routing
+   purposes with respect to the RAs to which they are attached, to the
+   containing RA, or when smaller groupings are required.
+
+3.5.2.  Commonly Advertised Information
+
+   Advertisements MAY contain the following common set of information
+   regardless of whether they are link or node related:
+
+   -  RA ID of the RA to which the advertisement is bounded
+
+   -  RC ID of the entity generating the advertisement
+
+
+
+
+Brungard, Ed.                Informational                      [Page 9]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+   -  Information to uniquely identify advertisements
+
+   -  Information to determine whether an advertisement has been updated
+
+   -  Information to indicate when an advertisement has been derived
+      from a different level RA
+
+3.5.3.  Node Attributes
+
+   All nodes belong to an RA; hence, the RA ID can be considered an
+   attribute of all nodes.  Given that no distinction is made between
+   abstract nodes and those that cannot be decomposed any further, the
+   same attributes MAY be used for their advertisement.  In the
+   following tables, Capability refers to the level of support required
+   in the realization of a link state routing protocol, whereas Usage
+   refers to the degree of operational control that SHOULD be available
+   to the operator.
+
+   The following Node Attributes are defined:
+
+      Attribute        Capability      Usage
+      -----------      -----------     ---------
+      Node ID          REQUIRED        REQUIRED
+      Reachability     REQUIRED        OPTIONAL
+
+               Table 1. Node Attributes
+
+   Reachability information describes the set of endpoints that are
+   reachable by the associated node.  It MAY be advertised as a set of
+   associated external (e.g., User Network Interface (UNI))
+   address/address prefixes or a set of associated SNPP link IDs/SNPP ID
+   prefixes, the selection of which MUST be consistent within the
+   applicable scope.  These are control plane identifiers; the formats
+   of these identifiers in a protocol realization are implementation
+   specific and outside the scope of this document.
+
+   Note: No distinction is made between nodes that may have further
+   internal details (i.e., abstract nodes) and those that cannot be
+   decomposed any further.  Hence, the attributes of a node are not
+   considered as only single-switch attributes but MAY apply to a node
+   at a higher level of the hierarchy that represents a subnetwork.
+
+
+
+
+
+
+
+
+
+
+Brungard, Ed.                Informational                     [Page 10]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+3.5.4.  Link Attributes
+
+   The following Link Attributes are defined:
+
+      Link Attribute                   Capability      Usage
+      ---------------                  -----------     ---------
+      Local SNPP link ID               REQUIRED        REQUIRED
+      Remote SNPP link ID              REQUIRED        REQUIRED
+      Layer Specific Characteristics   see Table 3
+
+                        Table 2. Link Attributes
+
+   The SNPP link ID MUST be sufficient to uniquely identify (within the
+   Node ID scope) the corresponding transport plane resource, taking
+   into account the separation of data and control planes (see Section
+   3.5.1; the control plane representation and transport plane topology
+   are not assumed to be congruent).  The SNPP link ID format is routing
+   protocol specific.
+
+   Note: When the remote end of an SNPP link is located outside of the
+   RA, the remote SNPP link ID is OPTIONAL.
+
+   The following link characteristic attributes are defined:
+
+   -  Signal Type: This identifies the characteristic information of the
+      layer network.
+
+   -  Link Weight: This is the metric indicating the relative
+      desirability of a particular link over another, e.g., during path
+      computation.
+
+   -  Resource Class: This corresponds to the set of administrative
+      groups assigned by the operator to this link.  A link MAY belong
+      to zero, one, or more administrative groups.
+
+   -  Local Connection Types: This attribute identifies whether the
+      local SNP represents a Termination Connection Point (CP), a
+      Connection Point (CP), or can be flexibly configured as a TCP.
+
+   -  Link Capacity: This provides the sum of the available and
+      potential bandwidth capacity for a particular network transport
+      layer.  Other capacity measures MAY be further considered.
+
+   -  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.
+
+
+
+Brungard, Ed.                Informational                     [Page 11]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+   -  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.
+
+
+
+
+
+
+Brungard, Ed.                Informational                     [Page 12]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+   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
+
+
+
+Brungard, Ed.                Informational                     [Page 13]
+
+RFC 4258                 GMPLS Routing for ASON            November 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 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
+
+
+
+Brungard, Ed.                Informational                     [Page 14]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brungard, Ed.                Informational                     [Page 15]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+Brungard, Ed.                Informational                     [Page 16]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+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.
+
+
+
+
+Brungard, Ed.                Informational                     [Page 17]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+   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.
+
+
+
+Brungard, Ed.                Informational                     [Page 18]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+Brungard, Ed.                Informational                     [Page 19]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+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
+
+
+
+
+
+Brungard, Ed.                Informational                     [Page 20]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+   Stephen Shew
+   Nortel Networks
+   PO Box 3511 Station C
+   Ottawa, Ontario, CANADA K1Y 4H7
+
+   Phone: +1 613 7632462
+   EMail: sdshew@nortelnetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brungard, Ed.                Informational                     [Page 21]
+
+RFC 4258                 GMPLS Routing for ASON            November 2005
+
+
+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.
+
+
+
+
+
+
+
+Brungard, Ed.                Informational                     [Page 22]
+