summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4652.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4652.txt')
-rw-r--r--doc/rfc/rfc4652.txt1235
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc4652.txt b/doc/rfc/rfc4652.txt
new file mode 100644
index 0000000..a41fd8b
--- /dev/null
+++ b/doc/rfc/rfc4652.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group D. Papadimitriou, Ed.
+Request for Comments: 4652 Alcatel
+Category: Informational L.Ong
+ Ciena
+ J. Sadler
+ Tellabs
+ S. Shew
+ Nortel
+ D. Ward
+ Cisco
+ October 2006
+
+
+ Evaluation of Existing Routing Protocols against
+ Automatic Switched Optical Network (ASON) Routing Requirements
+
+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 (2006).
+
+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 Synchronous Optical Network/Synchronous Digital Hierarchy
+ (SONET/SDH) and Optical Transport Networks (OTNs).
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Papadimitriou, et al. Informational [Page 1]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+1. Introduction
+
+ Certain capabilities are needed to support the ITU-T Automatically
+ Switched Optical Network (ASON) control plane architecture as defined
+ in [G.8080].
+
+ [RFC4258] 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 to facilitate management of ASON networks.
+ This description is only conceptual: no physical partitioning of
+ these functions is implied.
+
+ However, [RFC4258] does not address GMPLS routing protocol
+ applicability or capabilities. This document evaluates the IETF
+ Routing Protocols against the requirements identified in [RFC4258].
+ 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 Appendices A and
+ B.
+
+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].
+
+ The reader is expected to be familiar with the terminology introduced
+ in [RFC4258].
+
+3. Contributors
+
+ This document is the result of the CCAMP Working Group ASON Routing
+ Solution design team's joint effort.
+
+ Dimitri Papadimitriou (Alcatel, Team Leader and Editor)
+ EMail: dimitri.papadimitriou@alcatel.be
+ Chris Hopps (Cisco)
+ EMail: chopps@rawdofmt.org
+ Lyndon Ong (Ciena Corporation)
+ EMail: lyong@ciena.com
+ Jonathan Sadler (Tellabs)
+ EMail: jonathan.sadler@tellabs.com
+
+
+
+Papadimitriou, et al. Informational [Page 2]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+ Stephen Shew (Nortel Networks)
+ EMail: sdshew@nortel.com
+ Dave Ward (Cisco)
+ EMail: dward@cisco.com
+
+4. Requirements: Overview
+
+ The following functionality is expected from GMPLS routing protocols
+ 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
+ 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 are 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.
+
+
+
+Papadimitriou, et al. Informational [Page 3]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+ 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 as 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,
+ 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 [RFC4258] in Section
+ 4. Candidate routing protocols are Interior Gateway Protocol (IGP)
+ (OSPF and Intermediate System to Intermediate System (IS-IS)) and
+ BGP. The latter is not addressed in the current version of this
+ document. BGP is not considered a candidate protocol mainly because
+ of the following reasons:
+
+ - Non-support of TE information exchange. Each BGP router advertises
+ only its path to each destination in its vector for loop avoidance,
+ with no costs or hop counts; each BGP router knows little about
+ network topology.
+
+ - BGP can only advertise routes that are eligible for use (local RIB)
+ or routing loops can occur; there is one best route per prefix, and
+ that is the route that is advertised.
+
+ - BGP is not widely deployed in optical equipment and networks.
+
+5.1. Terminology and Identification
+
+ - Pi is a physical (bearer/data/transport plane) node.
+
+ - Li is a logical control plane entity that is associated to a single
+ data plane (abstract) node. The Li is identified by the TE
+ Router_ID. The latter is a control plane identifier defined as
+ follows:
+
+
+
+Papadimitriou, et al. Informational [Page 4]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+ [RFC3630]: Router_Address (top level) TLV of the Type 1 TE LSA
+ [RFC3784]: Traffic Engineering Router ID TLV (Type 134)
+
+ Note: This document does not define what the TE Router ID is. This
+ document simply states the use of the TE Router ID to identify Li.
+ [RFC3630] and [RFC3784] provide the definitions.
+
+ - Ri is a logical control plane entity that is associated to a
+ control plane "router". The latter is the source for topology
+ information that it generates and shares with other control plane
+ "routers". The Ri is identified by the (advertising) Router_ID
+
+ [RFC2328]: Router ID (32-bit)
+ [RFC1195]: IS-IS System ID (48-bit)
+
+ The Router_ID, which is represented by Ri and which corresponds to
+ the RC_ID [RFC4258], 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. Note
+ that, in the ASON context, an arrangement consisting of multiple
+ Ris announcing routing information related to a single Li is under
+ evaluation.
+
+ Aside from the Li/Pi mappings, these identifiers are not assumed to
+ be in a particular entity relationship except that the Ri may have
+ multiple Lis in its scope. The relationship between Ri and Li is
+ simple at any moment in time: an Li may be advertised by only one Ri
+ at any time. However, an Ri may advertise a set of one or more Lis.
+ Thus, the routing protocol MUST be able to advertise multiple TE
+ Router IDs (see Section 5.7).
+
+ Note: Si is a control plane signaling function associated with one or
+ more Lis. This document does not assume any specific constraint on
+ the relationship between Si and Li. This document does not discuss
+ issues of control plane accessibility for the signaling function, and
+ it makes no assumptions about how control plane accessibility to the
+ Si is achieved.
+
+5.2. RA Identification
+
+ G.7715.1 notes some necessary characteristics for RA identifiers,
+ e.g., that they may provide scope for the Ri, and that they must be
+ provisioned to be unique within an administrative domain. The RA ID
+ format itself is allowed to be derived from any global address space.
+ Provisioning of RA IDs for uniqueness is outside the scope of this
+ document.
+
+
+
+
+
+Papadimitriou, et al. Informational [Page 5]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+ Under these conditions, GMPLS link state routing protocols provide
+ the capability for RA Identification without further modification.
+
+5.3. Routing Information Exchange
+
+ In this section, the focus is on routing information exchange Ri
+ entities (through routing adjacencies) within a single hierarchical
+ level. Routing information mapping between levels require specific
+ processing (see Section 5.5).
+
+ The control plane does not transport Pi identifiers, as these are
+ data plane addresses for which the Li/Pi mapping is kept (link)
+ local; see, for instance the transport LMP document [RFC4394] where
+ such an exchange is described. Example: The transport plane
+ identifier is the Pi (the identifier assigned to the physical
+ element) that could be, for instance, "666B.F999.AF10.222C", whereas
+ the control plane identifier is the Li (the identifier assigned by
+ the control plane), which could be, for instance, "192.0.2.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 "192.0.2.1"). The mapping Li/Pi is
+ kept local. So, when the Si receives a control plane message
+ requesting the use of "192.0.2.1", Si knows locally that this
+ information refers to the data plane entity identified by the
+ transport plane identifier "666B.F999.AF10.222C".
+
+ Note also that the Li and Pi addressing spaces may be identical.
+
+ 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 Lis, i.e., referred to as an
+ associated IPv4/IPv6 addressing space. Note that these
+ identifiers may be either bundled TE link addresses or component
+ link addresses.
+
+ 3) when using OSPF or ISIS as the IGP in support of traffic
+ engineering, [RFC3477] RECOMMENDS that the Li value (referred to
+ the "LSR Router ID") be set to the TE Router ID value.
+
+ Therefore, OSPF and IS-IS carry sufficient node identification
+ information without further modification.
+
+
+
+
+
+
+Papadimitriou, et al. Informational [Page 6]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+5.3.1. Link Attributes
+
+ [RFC4258] provides a list of link attributes and characteristics that
+ need to be advertised by a routing protocol. All TE link attributes
+ and characteristics are currently handled by OSPF and IS-IS (see
+ Table 1) with the exception of Local Adaptation support. Indeed,
+ GMPLS routing does not currently consider the use of dedicated TE
+ link attribute(s) to describe the cross/inter-layer relationships.
+
+ In addition, the representation of bandwidth requires further
+ consideration. GMPLS Routing defines an Interface Switching
+ Capability Descriptor (ISCD) that delivers information about the
+ (maximum/ minimum) bandwidth per priority of which an LSP can make
+ use. This information is usually used in combination with the
+ Unreserved Bandwidth sub-TLV that provides the amount of bandwidth
+ not yet reserved on a TE link.
+
+ In the ASON context, other bandwidth accounting representations are
+ possible, e.g., in terms of a set of tuples <signal_type; number of
+ unallocated timeslots>. The latter representation may also require
+ definition of additional signal types (from those defined in
+ [RFC3946]) to represent support of contiguously concatenated signals,
+ i.e., STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256.
+
+ However, the method proposed in [RFC4202] is the most straightforward
+ without requiring any bandwidth accounting change from an LSR
+ perspective (in particular, when the ISCD sub-TLV information is
+ combined with the information provided by the Unreserved Bandwidth
+ sub-TLV).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Papadimitriou, et al. Informational [Page 7]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+ Link Characteristics GMPLS OSPF
+ ----------------------- ----------
+ Local SNPP link ID Link-local part of the TE link identifier
+ sub-TLV [RFC4203]
+ Remote SNPP link ID Link remote part of the TE link identifier
+ sub-TLV [RFC4203]
+ Signal Type Technology specific part of the Interface
+ Switching Capability Descriptor sub-TLV
+ [RFC4203]
+ Link Weight TE metric sub-TLV [RFC3630]
+ Resource Class Administrative Group sub-TLV [RFC3630]
+ Local Connection Types Switching Capability field part of the
+ Interface Switching Capability Descriptor
+ sub-TLV [RFC4203]
+ Link Capacity Unreserved bandwidth sub-TLV [RFC3630]
+ Max LSP Bandwidth part of the Interface
+ Switching Capability Descriptor sub-TLV
+ [RFC4203]
+ Link Availability Link Protection sub-TLV [RFC4203]
+ Diversity Support SRLG sub-TLV [RFC4203]
+ Local Adaptation support See above
+
+ Table 1. TE link attributes in GMPLS OSPF-TE
+
+ Link Characteristics GMPLS IS-IS
+ ----------------------- -----------
+ Local SNPP link ID Link-local part of the TE link identifier
+ sub-TLV [RFC4205]
+ Remote SNPP link ID Link-remote part of the TE link identifier
+ sub-TLV [RFC4205]
+ Signal Type Technology specific part of the Interface
+ Switching Capability Descriptor sub-TLV
+ [RFC4205]
+ Link Weight TE Default metric [RFC3784]
+ Resource Class Administrative Group sub-TLV [RFC3784]
+ Local Connection Types Switching Capability field part of the
+ Interface Switching Capability Descriptor
+ sub-TLV [RFC4205]
+ Link Capacity Unreserved bandwidth sub-TLV [RFC3784]
+ Max LSP Bandwidth part of the Interface
+ Switching Capability Descriptor sub-TLV
+ [RFC4205]
+ Link Availability Link Protection sub-TLV [RFC4205]
+ Diversity Support SRLG sub-TLV [RFC4205]
+ Local Adaptation support See above
+
+ Table 2. TE link attributes in GMPLS IS-IS-TE
+
+
+
+
+Papadimitriou, et al. Informational [Page 8]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+ Note: Link Attributes represent layer resource capabilities and
+ their utilization i.e. the IGP should be able to advertise these
+ attributes on a per-layer basis.
+
+5.3.2. Node Attributes
+
+ Node attributes are the "Logical Node ID" (described in Section 5.1)
+ and the reachability information described in Section 5.3.3.
+
+5.3.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 an OSPF TE LSA node attribute TLV (a specific sub-TLV is
+ defined per address family, e.g., IPv4 and IPv6). However,
+ [OSPF-NODE] is restricted to advertisement of Host addresses and not
+ prefixes, and therefore it requires enhancement (see below). Thus,
+ in order to advertise blocks of reachable address prefixes a
+ summarization mechanism is additionally required. This mechanism may
+ take the form of a prefix length (which indicates the number of
+ significant bits in the prefix) or a network mask.
+
+ A similar mechanism does not exist for IS-IS. Moreover, the Extended
+ IP Reachability TLV [RFC3784] focuses on IP reachable end-points
+ (terminating points), as its name indicates.
+
+5.4. Routing Information Abstraction
+
+ G.7715.1 describes both static and dynamic methods for abstraction of
+ routing information for advertisement at a different level of the
+ routing hierarchy. However, the information that is advertised
+ continues to be in the form of link and node advertisements
+ consistent with the link state routing protocol used at that level.
+ Hence, no specific capabilities need to be added to the routing
+ protocol beyond the ability to locally identify when routing
+ information originates outside of a particular RA.
+
+ The methods used for abstraction of routing information are outside
+ the scope of GMPLS routing protocols.
+
+5.5. Dissemination of Routing Information in Support of Multiple
+ Hierarchal Levels of RAs
+
+ G.7715.1 does not define specific mechanisms to support multiple
+ hierarchical levels of RAs beyond the ability to support abstraction
+ as discussed above. However, if RCs bound to adjacent levels of the
+ RA hierarchy are allowed to redistribute routing information in both
+
+
+
+
+Papadimitriou, et al. Informational [Page 9]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+ directions between adjacent levels of the hierarchy without any
+ additional mechanisms, they would not be able to determine looping of
+ routing information.
+
+ To prevent this looping of routing information between levels, IS-IS
+ [RFC1195] allows only advertising routing information upward in the
+ level hierarchy and disallows the advertising of routing information
+ downward in the hierarchy. [RFC2966] defines the up/down bit to
+ allow advertising downward in the hierarchy the "IP Internal
+ Reachability Information" TLV (Type 128) and "IP External
+ Reachability Information" TLV (Type 130). [RFC3784] extends its
+ applicability for the "Extended IP Reachability" TLV (Type 135).
+ Using this mechanism, the up/down bit is set to 0 when routing
+ information is first injected into IS-IS. If routing information is
+ advertised from a higher level to a lower level, the up/down bit is
+ set to 1, indicating that it has traveled down the hierarchy.
+ Routing information that has the up/down bit set to 1 may only be
+ advertised down the hierarchy, i.e., to lower levels. This mechanism
+ applies independently of the number of levels. However, this
+ mechanism does not apply to the "Extended IS Reachability" TLV (Type
+ 22) used to propagate the summarized topology (see Section 5.3),
+ traffic engineering information as listed in Table 1, as well as
+ reachability information (see Section 5.3.3).
+
+ OSPFv2 [RFC2328] prevents inter-area routes (which are learned from
+ area 0) from being passed back to area 0. However, GMPLS makes use
+ of Type 10 (area-local scope) LSAs to propagate TE information
+ [RFC3630], [RFC4202]. Type 10 Opaque LSAs are not flooded beyond the
+ borders of their associated area. It is therefore necessary to have
+ a means by which Type 10 Opaque LSA may carry the information that a
+ particular piece of routing information has been learned from a
+ higher-level RC when propagated to a lower-level RC. Any downward RC
+ from this level, which receives an LSA with this information would
+ omit the information in this LSA and thus not re-introduce this
+ information back into a higher-level RC.
+
+5.6. Routing Protocol Convergence
+
+ Link state protocols have been designed to propagate detected
+ topological changes (such as interface failures and link attributes
+ modification). The convergence period is short and involves a
+ minimum of routing information exchange.
+
+ Therefore, existing routing protocol convergence involves mechanisms
+ that are sufficient for ASON applications.
+
+
+
+
+
+
+Papadimitriou, et al. Informational [Page 10]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+5.7. Routing Information Scoping
+
+ The routing protocol MUST support a single Ri advertising on behalf
+ of more than one Li. Since each Li is identified by a unique TE
+ Router ID, the routing protocol MUST be able to advertise multiple TE
+ Router IDs. That is, for [RFC3630], multiple Router Addresses and
+ for [RFC3784] multiple Traffic Engineering Router Ids.
+
+ The Link sub-TLV that is currently part of the top level Link TLV
+ associates the link to the Router_ID. However, having the Ri
+ advertising on behalf of multiple Lis creates the following issue, as
+ there is no longer a 1:1 relationship between the Router_ID and the
+ TE Router_ID, but a 1:N relationship is possible (see Section 5.1).
+ As the link-local and link-remote (unnumbered) ID association may not
+ be unique per abstract node (per Li unicity), the advertisement needs
+ to indicate the remote Lj value and rely on the initial discovery
+ process to retrieve the {Li;Lj} relationship(s). In brief, as
+ unnumbered links have their ID defined on per Li bases, the remote Lj
+ needs to be identified to scope the link remote ID to the local Li.
+ Therefore, the routing protocol MUST be able to disambiguate the
+ advertised TE links so that they can be associated with the correct
+ TE Router ID.
+
+ Moreover, when the Ri advertises on behalf multiple Lis, the routing
+ protocol MUST be able to disambiguate the advertised reachability
+ information (see Section 5.3.3) so that it can be associated with the
+ correct TE Router ID.
+
+6. Evaluation Scenarios
+
+ The evaluation scenarios are the following; they are respectively
+ referred to as cases 1, 2, 3, and 4.
+
+ In Figure 1, below,
+
+ - 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Papadimitriou, et al. Informational [Page 11]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+ ------------------- -------
+ |R1 | |R2 |
+ | | | | ------
+ | L1 L2 L3 | | L4 | |R3 |
+ | : : : | | : | | |
+ | : : : | | : | | L5 |
+ Control ---+-----+-----+--- ---+--- | : |
+ Plane : : : : | : |
+ ----------------+-----+-----+-----------+-------+---+--+-
+ Data : : : : | : |
+ Plane -- : -- -- | -- |
+ ----|P1|--------|P3|--------|P4|------+-|P5|-+-
+ -- \ : / -- -- | -- |
+ \ -- / | |
+ |P2| ------
+ --
+
+ Figure 1. Evaluation Cases 1, 2, and 3
+
+ Case 1 as represented refers either to direct links between edges or
+ to "logical links" as shown in Figure 2 (or any combination of them).
+
+ ------ ------
+ | | | |
+ | L1 | | L2 |
+ | : | | : |
+ | : R1| | : R2|
+ Control Plane --+--- --+---
+ Elements : :
+ ------------------+-----------------------------+------------------
+ Data Plane : :
+ Elements : :
+ ----+-----------------------------+-----
+ | : : |
+ | --- --- --- |
+ | | |----------| P |----------| | |
+ ---+--| | --- | |---+---
+ | | | | | |
+ | | P1|-------------------------| P2| |
+ | --- --- |
+ ----------------------------------------
+
+ Figure 2. Case 1 with Logical Links
+
+ Another case (referred to as Case 4) is constituted by the Abstract
+ Node as represented in Figure 3. There is no internal structure
+ associated (externally) to the abstract node.
+
+
+
+
+Papadimitriou, et al. Informational [Page 12]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+ --------------
+ |R4 |
+ | |
+ | L6 |
+ | : |
+ | ...... |
+ ---:------:---
+ Control Plane : :
+ +------+------+------+
+ Data Plane : :
+ ---:------:---
+ |P8 : : |
+ | -- -- |
+ --+-|P |----|P |-+--
+ | -- -- |
+ --------------
+
+ Figure 3. Case 4: Abstract Node
+
+ Note: the "signaling function" referred to as Si, i.e., the control
+ plane entity that processes the signaling messages, is not
+ represented in these figures.
+
+7. Summary of Necessary Additions to OSPF and IS-IS
+
+ The following sections summarize the additions to be provided to OSPF
+ and IS-IS in support of ASON routing.
+
+7.1. OSPFv2
+
+ Reachability Extend Node Attribute sub-TLVs to support address
+ prefixes (see Section 5.3.3).
+
+ Link Attributes Representation of cross/inter-layer relationships
+ in link top-level link TLV (see Section 5.3.1).
+
+ Optionally, provide for per-signal-type bandwidth
+ accounting (see Section 5.3.1).
+
+ Scoping TE link advertisements to allow for retrieving
+ their respective local-remote TE Router_ID
+ relationship(s) (see Section 5.7).
+
+ Prefixes part of the reachability advertisement
+ (using Node Attribute top-level TLV) needs to be
+ associated to its respective local TE Router_ID
+ (see Section 5.7).
+
+
+
+
+Papadimitriou, et al. Informational [Page 13]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+ Hierarchy Provide a mechanism by which Type 10 Opaque LSA may
+ carry the information that a particular piece of
+ routing information has been learned from a
+ higher-level RC when propagated to a lower-level RC
+ (so as not to re-introduce this information into a
+ higher-level RC).
+
+7.2. IS-IS
+
+ Reachability Provide for reachability advertisement (in the form
+ of reachable TE prefixes).
+
+ Link Attributes Representation of cross/inter-layer relationships
+ in Extended IS Reachability TLV (see Section
+ 5.3.1).
+
+ Optionally, provide for per-signal-type bandwidth
+ accounting (see Section 5.3.1).
+
+ Scoping Extended IS Reachability TLVs to allow for
+ retrieving their respective local-remote TE
+ Router_ID relationship(s) (see Section 5.7).
+
+ Prefixes part of the reachability advertisement
+ needs to be associated to its respective local TE
+ Router_ID (see Section 5.7).
+
+ Hierarchy Extend the up/down bit mechanisms to propagate the
+ summarized topology (see Section 5.3) and traffic
+ engineering information as listed in Table 1, as
+ well as reachability information (see Section
+ 5.3.3).
+
+8. Security Considerations
+
+ The introduction of a dynamic control plane to an ASON network
+ exposes it to additional security risks that may have been controlled
+ or limited by the use of management plane solutions. The routing
+ protocols play a part in the control plane and may be attacked so
+ that they become unstable or provide incorrect information for use in
+ path computation or by the signaling protocols.
+
+ Nevertheless, there is no reason why the control plane components
+ cannot be secured, and the security mechanisms developed for the
+ routing protocol and used within the Internet are equally applicable
+ within an ASON context.
+
+
+
+
+
+Papadimitriou, et al. Informational [Page 14]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+ [RFC4258] describes the requirements for security of routing
+ protocols for the Automatically Switched Optical Network. Reference
+ is made to [M.3016], which lays out the overall security objectives
+ of confidentiality, integrity, and accountability. These are well
+ discussed for the Internet routing protocols in [THREATS].
+
+ A detailed discussion of routing threats and mechanisms that are
+ currently deployed in operational networks to counter these threats
+ is found in [OPSECPRACTICES]. A detailed listing of the device
+ capabilities that can be used to support these practices can be found
+ in [RFC3871].
+
+9. 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.
+
+10. References
+
+10.1. Normative References
+
+ [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP
+ and dual environments", RFC 1195, December 1990.
+
+ [RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide
+ Prefix Distribution with Two-Level IS-IS", RFC
+ 2966, October 2000.
+
+ [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
+ 1998.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
+ Links in Resource ReSerVation Protocol - Traffic
+ Engineering (RSVP-TE)", RFC 3477, January 2003.
+
+ [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
+ Engineering (TE) Extensions to OSPF Version 2", RFC
+ 3630, September 2003.
+
+ [RFC3784] Smit, H. and T. Li, "Intermediate System to
+ Intermediate System (IS-IS) Extensions for Traffic
+ Engineering (TE)", RFC 3784, June 2004.
+
+
+
+
+
+Papadimitriou, et al. Informational [Page 15]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+ [RFC3871] Jones, G., Ed., "Operational Security Requirements
+ for Large Internet Service Provider (ISP) IP
+ Network Infrastructure", RFC 3871, September 2004.
+
+ [RFC3946] Mannie, E. and D. Papadimitriou, "Generalized
+ Multi-Protocol Label Switching (GMPLS) Extensions
+ for Synchronous Optical Network (SONET) and
+ Synchronous Digital Hierarchy (SDH) Control", RFC
+ 3946, October 2004.
+
+ [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
+ Extensions in Support of Generalized Multi-Protocol
+ Label Switching (GMPLS)", RFC 4202, October 2005.
+
+ [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
+ Extensions in Support of Generalized Multi-Protocol
+ Label Switching (GMPLS)", RFC 4203, October 2005.
+
+ [RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed.,
+ "Intermediate System to Intermediate System (IS-IS)
+ Extensions in Support of Generalized Multi-Protocol
+ Label Switching (GMPLS)", RFC 4205, October 2005.
+
+ [RFC4258] Brungard, D., "Requirements for Generalized Multi-
+ Protocol Label Switching (GMPLS) Routing for the
+ Automatically Switched Optical Network (ASON)", RFC
+ 4258, November 2005.
+
+10.2. Informative References
+
+ [RFC4394] Fedyk, D., Aboul-Magd, O., Brungard, D., Lang, J.,
+ and D. Papadimitriou, "A Transport Network View of
+ the Link Management Protocol (LMP)", RFC 4394,
+ February 2006.
+
+ [OPSECPRACTICES] Kaeo, M., "Operational Security Current Practices",
+ Work in Progress, July 2006.
+
+ [OSPF-NODE] Aggarwal, R. and K. Kompella, "Advertising a
+ Router's Local Addresses in OSPF TE Extensions",
+ Work in Progress, June 2006.
+
+ [THREATS] Barbir, A., Murphy, S., and Y. Yang, "Generic
+ Threats to Routing Protocols", RFC 4593, October
+ 2006.
+
+
+
+
+
+
+Papadimitriou, et al. Informational [Page 16]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+ 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)",
+ June 2006.
+
+ [M.3016] ITU-T Rec. M.3016.0, "Security for the Management
+ Plane: Overview", May 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Papadimitriou, et al. Informational [Page 17]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+Appendix A. 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.
+
+ 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 fault, configuration, accounting, performance, and 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.
+
+
+
+Papadimitriou, et al. Informational [Page 18]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+ 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
+ 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.
+
+Appendix B. 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 sub-networks, 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 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 that may additionally
+ contain information that is configured. The RDB may contain routing
+ information for more than one Routing Area (RA).
+
+
+
+
+
+
+
+Papadimitriou, et al. Informational [Page 19]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+ Routing Components: ASON routing architecture functions. These
+ functions can be classified as being 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Papadimitriou, et al. Informational [Page 20]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+Authors' Addresses
+
+ Dimitri Papadimitriou, Ed.
+ Alcatel
+ Francis Wellensplein 1,
+ B-2018 Antwerpen, Belgium
+ Phone: +32 3 2408491
+ EMail: dimitri.papadimitriou@alcatel.be
+
+ Lyndon Ong
+ Ciena Corporation
+ PO Box 308
+ Cupertino, CA 95015 , USA
+ Phone: +1 408 705 2978
+ EMail: lyong@ciena.com
+
+ Jonathan Sadler
+ Tellabs
+ 1415 W. Diehl Rd
+ Naperville, IL 60563
+ EMail: jonathan.sadler@tellabs.com
+
+ Stephen Shew
+ Nortel Networks
+ 3500 Carling Ave.
+ Ottawa, Ontario, CANADA K2H 8E9
+ Phone: +1 613 7632462
+ EMail: sdshew@nortel.com
+
+ Dave Ward
+ Cisco Systems
+ 170 W. Tasman Dr.
+ San Jose, CA 95134 USA
+ Phone: +1-408-526-4000
+ EMail: dward@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Papadimitriou, et al. Informational [Page 21]
+
+RFC 4652 Evaluation of Routing Protocols against ASON October 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ 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 provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Papadimitriou, et al. Informational [Page 22]
+