tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7926


Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks

Part 2 of 3, p. 22 to 43
Prev Section       Next Section


prevText      Top      ToC       Page 22 
4.  Architecture

4.1.  TE Reachability

   As described in Section 1.1, TE reachability is the ability to reach
   a specific address along a TE path.  The knowledge of TE reachability
   enables an end-to-end TE path to be computed.

   In a single network, TE reachability is derived from the Traffic
   Engineering Database (TED), which is the collection of all TE
   information about all TE links in the network.  The TED is usually
   built from the data exchanged by the IGP, although it can be
   supplemented by configuration and inventory details, especially in
   transport networks.

   In multi-network scenarios, TE reachability information can be
   described as "You can get from node X to node Y with the following TE
   attributes."  For transit cases, nodes X and Y will be edge nodes of
   the transit network, but it is also important to consider the
   information about the TE connectivity between an edge node and a
   specific destination node.  TE reachability may be qualified by TE
   attributes such as TE metrics, hop count, available bandwidth, delay,
   and shared risk.

   TE reachability information can be exchanged between networks so that
   nodes in one network can determine whether they can establish TE
   paths across or into another network.  Such exchanges are subject to
   a range of policies imposed by the advertiser (for security and
   administrative control) and by the receiver (for scalability and

4.2.  Abstraction, Not Aggregation

   Aggregation is the process of synthesizing from available
   information.  Thus, the virtual node and virtual link models
   described in Section 3.5 rely on processing the information available
   within a network to produce the aggregate representations of links
   and nodes that are presented to the consumer.  As described in
   Section 3, dynamic aggregation is subject to a number of pitfalls.

   In order to distinguish the architecture described in this document
   from the previous work on aggregation, we use the term "abstraction"
   in this document.  The process of abstraction is one of applying
   policy to the available TE information within a domain, to produce
   selective information that represents the potential ability to
   connect across the domain.

Top      Up      ToC       Page 23 
   Abstraction does not offer all possible connectivity options (refer
   to Section 3.5) but does present a general view of potential
   connectivity.  Abstraction may have a dynamic element but is not
   intended to keep pace with the changes in TE attribute availability
   within the network.

   Thus, when relying on an abstraction to compute an end-to-end path,
   the process might not deliver a usable path.  That is, there is no
   actual guarantee that the abstractions are current or feasible.

   Although abstraction uses available TE information, it is subject to
   policy and management choices.  Thus, not all potential connectivity
   will be advertised to each client network.  The filters may depend on
   commercial relationships, the risk of disclosing confidential
   information, and concerns about what use is made of the connectivity
   that is offered.

4.2.1.  Abstract Links

   An abstract link is a measure of the potential to connect a pair of
   points with certain TE parameters.  That is, it is a path and its
   characteristics in the server network.  An abstract link represents
   the possibility of setting up an LSP, and LSPs may be set up over the
   abstract link.

   When looking at a network such as the network shown in Figure 7, the
   link from CN1 to CN4 may be an abstract link.  It is easy to
   advertise it as a link by abstracting the TE information in the
   server network, subject to policy.

   The path (i.e., the abstract link) represents the possibility of
   establishing an LSP from client network edge to client network edge
   across the server network.  There is not necessarily a one-to-one
   relationship between the abstract link and the LSP, because more than
   one LSP could be set up over the path.

   Since the client network nodes do not have visibility into the server
   network, they must rely on abstraction information delivered to them
   by the server network.  That is, the server network will report on
   the potential for connectivity.

4.2.2.  The Abstraction Layer Network

   Figure 7 introduces the abstraction layer network.  This construct
   separates the client network resources (nodes C1, C2, C3, and C4, and
   the corresponding links) and the server network resources (nodes CN1,
   CN2, CN3, and CN4, and the corresponding links).  Additionally, the
   architecture introduces an intermediary network layer called the

Top      Up      ToC       Page 24 
   abstraction layer.  The abstraction layer contains the client network
   edge nodes (C2 and C3), the server network edge nodes (CN1 and CN4),
   the client-server links (C2-CN1 and CN4-C3), and the abstract link

   The client network is able to operate as normal.  Connectivity across
   the network can be either found or not found, based on links that
   appear in the client network TED.  If connectivity cannot be found,
   end-to-end LSPs cannot be set up.  This failure may be reported, but
   no dynamic action is taken by the client network.

   The server network also operates as normal.  LSPs across the server
   network between client network edges are set up in response to
   management commands or in response to signaling requests.

   The abstraction layer consists of the physical links between the two
   networks, and also the abstract links.  The abstract links are
   created by the server network according to local policy and represent
   the potential connectivity that could be created across the server
   network and that the server network is willing to make available for
   use by the client network.  Thus, in this example, the diameter of
   the abstraction layer network is only three hops, but an instance of
   an IGP could easily be run so that all nodes participating in the
   abstraction layer (and, in particular, the client network edge nodes)
   can see the TE connectivity in the layer.

    --    --                                  --    --
   |C1|--|C2|                                |C3|--|C4|   Client Network
    --   |  |                                |  |   --
         |  |                                |  |  . . . . . . . . . . .
         |  |                                |  |
         |  |                                |  |
         |  |    ---                  ---    |  |          Abstraction
         |  |---|CN1|================|CN4|---|  |         Layer Network
          --    |   |                |   |    --
                |   |                |   |   . . . . . . . . . . . . . .
                |   |                |   |
                |   |                |   |
                |   |   ---    ---   |   |                Server Network
                |   |--|CN2|--|CN3|--|   |
                 ---    ---    ---    ---

    --- Direct connection between two nodes
    === Abstract link

           Figure 7: Architecture for Abstraction Layer Network

Top      Up      ToC       Page 25 
   When the client network needs additional connectivity, it can make a
   request to the abstraction layer network.  For example, the operator
   of the client network may want to create a link from C2 to C3.  The
   abstraction layer can see the potential path C2-CN1-CN4-C3 and can
   set up an LSP C2-CN1-CN4-C3 across the server network and make the
   LSP available as a link in the client network.

   Sections 4.2.3 and 4.2.4 show how this model is used to satisfy the
   requirements for connectivity in client-server networks and in peer
   networks.  Nodes in the Abstraction Layer Network

   Figure 7 shows a very simplified network diagram, and the reader
   would be forgiven for thinking that only client network edge nodes
   and server network edge nodes may appear in the abstraction layer
   network.  But this is not the case: other nodes from the server
   network may be present.  This allows the abstraction layer network to
   be more complex than a full mesh with access spokes.

   Thus, as shown in Figure 8, a transit node in the server network
   (here, the node is CN3) can be exposed as a node in the abstraction
   layer network with abstract links connecting it to other nodes in the
   abstraction layer network.  Of course, in the network shown in
   Figure 8, there is little if any value in exposing CN3, but if it had
   other abstract links to other nodes in the abstraction layer network
   and/or direct connections to client network nodes, then the resulting
   network would be richer.

    --    --                                     --    --     Client
   |C1|--|C2|                                   |C3|--|C4|    Network
    --   |  |                                   |  |   --
         |  |                                   |  |  . . . . . . . . .
         |  |                                   |  |
         |  |                                   |  |
         |  |   ---          ---          ---   |  |       Abstraction
         |  |--|CN1|========|CN3|========|CN5|--|  |      Layer Network
          --   |   |        |   |        |   |   --
               |   |        |   |        |   |  . . . . . . . . . . . .
               |   |        |   |        |   |
               |   |        |   |        |   |                 Server
               |   |   ---  |   |  ---   |   |                 Network
               |   |--|CN2|-|   |-|CN4|--|   |
                ---    ---   ---   ---    ---

         Figure 8: Abstraction Layer Network with Additional Node

Top      Up      ToC       Page 26 
   It should be noted that the nodes included in the abstraction layer
   network in this way are not "abstract nodes" in the sense of a
   virtual node described in Section 3.5.  Although it is the case that
   the policy point responsible for advertising server network resources
   into the abstraction layer network could choose to advertise abstract
   nodes in place of real physical nodes, it is believed that doing so
   would introduce significant complexity in terms of:

   -  Coordination between all of the external interfaces of the
      abstract node.

   -  Management of changes in the server network that lead to limited
      capabilities to reach (cross-connect) across the abstract node.
      There has been recent work on control-plane extensions to describe
      and operate devices (such as asymmetrical switches) that have
      limited cross-connect capabilities [RFC7579] [RFC7580].  These or
      similar extensions could be used to represent the same type of
      limitations, as they also apply in an abstract node.

4.2.3.  Abstraction in Client-Server Networks

   Figure 9 shows the basic architectural concepts for a client-server
   network.  The nodes in the client network are C1, C2, CE1, CE2, C3,
   and C4, where the client edge (CE) nodes are CE1 and CE2.  The core
   (server) network nodes are CN1, CN2, CN3, and CN4.  The interfaces
   CE1-CN1 and CE2-CN4 are the interfaces between the client and server

   The technologies (switching capabilities) of the client and server
   networks may be the same or different.  If they are different, the
   client network traffic must be tunneled over a server network LSP.
   If they are the same, the client network LSP may be routed over the
   server network links, tunneled over a server network LSP, or
   constructed from the concatenation (stitching) of client network and
   server network LSP segments.

Top      Up      ToC       Page 27 
                      :                            :
      Client Network  :       Server Network       :  Client Network
                      :                            :
     --    --    ---                                  ---    --    --
     --    --   |   |    ---                  ---    |   |   --    --
                |   |===|CN1|================|CN4|===|   |
                |   |---|   |                |   |---|   |
                 ---    |   |   ---    ---   |   |    ---
                        |   |--|CN2|--|CN3|--|   |
                         ---    ---    ---    ---

     --- Direct connection between two nodes
     ... CE-to-CE LSP tunnel
     === Potential path across the server network (abstract link)

             Figure 9: Architecture for Client-Server Network

   The objective is to be able to support an end-to-end connection,
   C1-to-C4, in the client network.  This connection may support TE or
   normal IP forwarding.  To achieve this, CE1 is to be connected to CE2
   by a link in the client network.  This enables the client network to
   view itself as connected and to select an end-to-end path.

   As shown in the figure, three abstraction layer links are formed:
   CE1-CN1, CN1-CN2, and CN4-CE2.  A three-hop LSP is then established
   from CE1 to CE2 that can be presented as a link in the client

   The practicalities of how the CE1-CE2 LSP is carried across the
   server network LSP may depend on the switching and signaling options
   available in the server network.  The CE1-CE2 LSP may be tunneled
   down the server network LSP using the mechanisms of a hierarchical
   LSP [RFC4206], or the LSP segments CE1-CN1 and CN4-CE2 may be
   stitched to the server network LSP as described in [RFC5150].

   Section 4.2.2 has already introduced the concept of the abstraction
   layer network through an example of a simple layered network.  But it
   may be helpful to expand on the example using a slightly more complex

Top      Up      ToC       Page 28 
   Figure 10 shows a multi-layer network comprising client network nodes
   (labeled as Cn for n = 0 to 9) and server network nodes (labeled as
   Sn for n = 1 to 9).

                                              --     --
                                             /--     --\
             --     --     --     --      --/           \--
            |C1|---|C2|---|S1|---|S2|----|S3|           |C5|
             --    /--     --\    --\     --\           /--
                  /           \--    \--     \--     --/    --
                 /            |S4|   |S5|----|S6|---|C6|---|C7|
                /             /--     --\    /--    /--     --
             --/    --     --/    --     \--/    --/
             --     --     --     --      --     --

                 Figure 10: An Example Multi-Layer Network

   If the network in Figure 10 is operated as separate client and server
   networks, then the client network topology will appear as shown in
   Figure 11.  As can be clearly seen, the network is partitioned, and
   there is no way to set up an LSP from a node on the left-hand side
   (say C1) to a node on the right-hand side (say C7).

                                    --     --
                                    --     --\
                    --     --                 \--
                   |C1|---|C2|                |C5|
                    --    /--                 /--
                         /                 --/    --
                        /                 |C6|---|C7|
                       /                  /--     --
                    --/    --          --/
                   |C8|---|C9|        |C0|
                    --     --          --

      Figure 11: Client Network Topology Showing Partitioned Network

Top      Up      ToC       Page 29 
   For reference, Figure 12 shows the corresponding server network

                          --     --      --
                          --\    --\     --\
                             \--    \--     \--
                             |S4|   |S5|----|S6|
                             /--     --\    /--
                          --/    --     \--/
                          --     --      --

                    Figure 12: Server Network Topology

   Operating on the TED for the server network, a management entity or a
   software component may apply policy and consider what abstract links
   it might offer for use by the client network.  To do this, it
   obviously needs to be aware of the connections between the layers
   (there is no point in offering an abstract link S2-S8, since this
   could not be of any use in this example).

   In our example, after consideration of which LSPs could be set up in
   the server network, four abstract links are offered: S1-S3, S3-S6,
   S1-S9, and S7-S9.  These abstract links are shown as double lines on
   the resulting topology of the abstraction layer network in Figure 13.
   As can be seen, two of the links must share part of a path (S1-S9
   must share with either S1-S3 or S7-S9).  This could be achieved using
   distinct resources (for example, separate lambdas) where the paths
   are common, but it could also be done using resource sharing.

                   --     --            --/
                   --     --\\          --\\
                             \\            \\
                              \\            \\--     --
                               \\            |S6|---|C6|
                                \\            --     --
                   --     --     \\--     --
                   --     --       --     --

         Figure 13: Abstraction Layer Network with Abstract Links

Top      Up      ToC       Page 30 
   That would mean that when both paths S1-S3 and S7-S9 carry
   client-edge-to-client-edge LSPs, the resources on path S1-S9 are used
   and might be depleted to the point that the path is resource
   constrained and cannot be used.

   The separate IGP instance running in the abstraction layer network
   means that this topology is visible at the edge nodes (C2, C3, C6,
   C9, and C0) as well as at a Path Computation Element (PCE) if one is

   Now the client network is able to make requests to the abstraction
   layer network to provide connectivity.  In our example, it requests
   that C2 be connected to C3 and that C2 be connected to C0.  This
   results in several actions:

   1. The management component for the abstraction layer network asks
      its PCE to compute the paths necessary to make the connections.
      This yields C2-S1-S3-C3 and C2-S1-S9-C0.

   2. The management component for the abstraction layer network
      instructs C2 to start the signaling process for the new LSPs in
      the abstraction layer.

   3. C2 signals the LSPs for setup using the explicit routes
      C2-S1-S3-C3 and C2-S1-S9-C0.

   4. When the signaling messages reach S1 (in our example, both LSPs
      traverse S1), the server network may support them by a number of
      means, including establishing server network LSPs as tunnels,
      depending on the mismatch of technologies between the client and
      server networks.  For example, S1-S2-S3 and S1-S2-S5-S9 might be
      traversed via an LSP tunnel, using LSPs stitched together, or
      simply by routing the client network LSP through the server
      network.  If server network LSPs are needed, they can be signaled
      at this point.

   5. Once any server network LSPs that are needed have been
      established, S1 can continue to signal the client-edge-to-client-
      edge LSP across the abstraction layer, using the server network
      LSPs as either tunnels or stitching segments, or simply routing
      through the server network.

   6. Finally, once the client-edge-to-client-edge LSPs have been set
      up, the client network can be informed and can start to advertise
      the new TE links C2-C3 and C2-C0.  The resulting client network
      topology is shown in Figure 14.

Top      Up      ToC       Page 31 
                                      --   --
                                     /--   --\
                                    /         \--
                          --     --/          |C5|
                         |C1|---|C2|          /--
                          --    /--\       --/    --
                               /    \     |C6|---|C7|
                              /      \    /--     --
                             /        \--/
                          --/    --   |C0|
                         |C8|---|C9|   --
                          --     --

         Figure 14: Connected Client Network with Additional Links

   7. Now the client network can compute an end-to-end path from C1
      to C7.  A Server with Multiple Clients

   A single server network may support multiple client networks.  This
   is not an uncommon state of affairs -- for example, when the server
   network provides connectivity for multiple customers.

   In this case, the abstraction provided by the server network may vary
   considerably according to the policies and commercial relationships
   with each customer.  This variance would lead to a separate
   abstraction layer network maintained to support each client network.

   On the other hand, it may be that multiple client networks are
   subject to the same policies and the abstraction can be identical.
   In this case, a single abstraction layer network can support more
   than one client.

   The choices here are made as an operational issue by the server
   network.  A Client with Multiple Servers

   A single client network may be supported by multiple server networks.
   The server networks may provide connectivity between different parts
   of the client network or may provide parallel (redundant)
   connectivity for the client network.

   In this case, the abstraction layer network should contain the
   abstract links from all server networks so that it can make suitable
   computations and create the correct TE links in the client network.

Top      Up      ToC       Page 32 
   That is, the relationship between the client network and the
   abstraction layer network should be one to one.

4.2.4.  Abstraction in Peer Networks

   Figure 15 shows the basic architectural concepts for connecting
   across peer networks.  Nodes from four networks are shown: A1 and A2
   come from one network; B1, B2, and B3 from another network; etc.  The
   interfaces between the networks (sometimes known as External Network
   Network Interfaces - ENNIs) are A2-B1, B3-C1, and C3-D1.

   The objective is to be able to support an end-to-end connection,
   A1-to-D2.  This connection is for TE connectivity.

   As shown in the figure, abstract links that span the transit networks
   are used to achieve the required connectivity.  These links form the
   key building blocks of the end-to-end connectivity.  An end-to-end
   LSP uses these links as part of its path.  If the stitching
   capabilities of the networks are homogeneous, then the end-to-end LSP
   may simply traverse the path defined by the abstract links across the
   various peer networks or may utilize stitching of LSP segments that
   each traverse a network along the path of an abstract link.  If the
   network switching technologies support or necessitate the use of LSP
   hierarchies, the end-to-end LSP may be tunneled across each network
   using hierarchical LSPs that each traverse a network along the path
   of an abstract link.

                 :                  :                  :
      Network A  :    Network B     :    Network C     :  Network D
                 :                  :                  :
       --    --     --    --    --     --    --    --     --    --
       --    --    |  |   --   |  |   |  |   --   |  |    --    --
                   |  |========|  |   |  |========|  |
                    --          --     --          --

      --- Direct connection between two nodes
      === Abstract link across transit network

                    Figure 15: Architecture for Peering

   Peer networks exist in many situations in the Internet.  Packet
   networks may peer as IGP areas (levels) or as ASes.  Transport
   networks (such as optical networks) may peer to provide
   concatenations of optical paths through single-vendor environments
   (see Section 6).  Figure 16 shows a simple example of three peer
   networks (A, B, and C) each comprising a few nodes.

Top      Up      ToC       Page 33 
                 Network A    :     Network B      :   Network C
                              :                    :
           --     --      --  :  --     --     --  :  --     --
           --     --\    /--  :  --    /--\    --  :  --     --
                     \--/     :       /    \       :
                     |A4|     :      /      \      :
                      --\     :     /        \     :
                   --    \--  :  --/          \--  :  --     --
                   --     --  :  --            --  :  --     --
                              :                    :
                              :                    :

            Figure 16: A Network Comprising Three Peer Networks

   As discussed in Section 2, peered networks do not share visibility of
   their topologies or TE capabilities for scaling and confidentiality
   reasons.  That means, in our example, that computing a path from A1
   to C4 can be impossible without the aid of cooperating PCEs or some
   form of crankback.

   But it is possible to produce abstract links for reachability across
   transit peer networks and to create an abstraction layer network.
   That network can be enhanced with specific reachability information
   if a destination network is partitioned, as is the case with
   Network C in Figure 16.

   Suppose that Network B decides to offer three abstract links B1-B3,
   B4-B3, and B4-B6.  The abstraction layer network could then be
   constructed to look like the network in Figure 17.

                        --     --      --      --
                        --     --    //--      --
                        --     --//     --     --
                        --     --       --     --

     Figure 17: Abstraction Layer Network for the Peer Network Example

   Using a process similar to that described in Section 4.2.3, Network A
   can request connectivity to Network C, and abstract links can be
   advertised that connect the edges of the two networks and that can be
   used to carry LSPs that traverse both networks.  Furthermore, if

Top      Up      ToC       Page 34 
   Network C is partitioned, reachability information can be exchanged
   to allow Network A to select the correct abstract link, as shown in
   Figure 18.

                       Network A       :      Network C
                 --     --      --     :     --       --
                 --     --\    /--     :     --       --
                           \--/        :
                           |A4|        :
                            --\        :
                         --    \--     :     --       --
                         --     --     :     --       --

      Figure 18: Tunnel Connections to Network C with TE Reachability

   Peer networking cases can be made far more complex by dual-homing
   between network peering nodes (for example, A3 might connect to B1
   and B4 in Figure 17) and by the networks themselves being arranged in
   a mesh (for example, A6 might connect to B4 and C1 in Figure 17).

   These additional complexities can be handled gracefully by the
   abstraction layer network model.

   Further examples of abstraction in peer networks can be found in
   Sections 6 and 8.

4.3.  Considerations for Dynamic Abstraction

   It is possible to consider a highly dynamic system where the server
   network adaptively suggests new abstract links into the abstraction
   layer, and where the abstraction layer proactively deploys new
   client-edge-to-client-edge LSPs to provide new links in the client
   network.  Such fluidity is, however, to be treated with caution.  In
   particular, in the case of client-server networks of differing
   technologies where hierarchical server network LSPs are used, this
   caution is needed for three reasons: there may be longer turn-up
   times for connections in some server networks; the server networks
   are likely to be sparsely connected; and expensive physical resources
   will only be deployed where there is believed to be a need for them.
   More significantly, the complex commercial, policy, and
   administrative relationships that may exist between client and server
   network operators mean that stability is more likely to be the
   desired operational practice.

Top      Up      ToC       Page 35 
   Thus, proposals for fully automated multi-layer networks based on
   this architecture may be regarded as forward-looking topics for
   research both in terms of network stability and with regard to
   economic impact.

   However, some elements of automation should not be discarded.  A
   server network may automatically apply policy to determine the best
   set of abstract links to offer and the most suitable way for the
   server network to support them.  And a client network may dynamically
   observe congestion, lack of connectivity, or predicted changes in
   traffic demand and may use this information to request additional
   links from the abstraction layer.  And, once policies have been
   configured, the whole system should be able to operate independently
   of operator control (which is not to say that the operator will not
   have the option of exerting control at every step in the process).

4.4.  Requirements for Advertising Links and Nodes

   The abstraction layer network is "just another network layer".  The
   links and nodes in the network need to be advertised along with their
   associated TE information (metrics, bandwidth, etc.) so that the
   topology is disseminated and so that routing decisions can be made.

   This requires a routing protocol running between the nodes in the
   abstraction layer network.  Note that this routing information
   exchange could be piggybacked on an existing routing protocol
   instance (subject to different switching capabilities applying to the
   links in the different networks, or to adequate address space
   separation) or use a new instance (or even a new protocol).  Clearly,
   the information exchanged is only information that has been created
   as part of the abstraction function according to policy.

   It should be noted that in many cases the abstract link represents
   the potential for connectivity across the server network but that
   no such connectivity exists.  In this case, we may ponder how the
   routing protocol in the abstraction layer will advertise topology
   information for, and over, a link that has no underlying
   connectivity.  In other words, there must be a communication channel
   between the abstraction layer nodes so that the routing protocol
   messages can flow.  The answer is that control-plane connectivity
   already exists in the server network and on the client-server edge
   links, and this can be used to carry the routing protocol messages
   for the abstraction layer network.  The same consideration applies to
   the advertisement, in the client network, of the potential
   connectivity that the abstraction layer network can provide, although
   it may be more normal to establish that connectivity before
   advertising a link in the client network.

Top      Up      ToC       Page 36 
4.5.  Addressing Considerations

   The network layers in this architecture should be able to operate
   with separate address spaces, and these may overlap without any
   technical issues.  That is, one address may mean one thing in the
   client network, yet the same address may have a different meaning in
   the abstraction layer network or the server network.  In other words,
   there is complete address separation between networks.

   However, this will require some care, both because human operators
   may well become confused, and because mapping between address spaces
   is needed at the interfaces between the network layers.  That mapping
   requires configuration so that, for example, when the server network
   announces an abstract link from A to B, the abstraction layer network
   must recognize that A and B are server network addresses and must map
   them to abstraction layer addresses (say P and Q) before including
   the link in its own topology.  And similarly, when the abstraction
   layer network informs the client network that a new link is available
   from S to T, it must map those addresses from its own address space
   to that of the client network.

   This form of address mapping will become particularly important in
   cases where one abstraction layer network is constructed from
   connectivity in multiple server networks, or where one abstraction
   layer network provides connectivity for multiple client networks.

5.  Building on Existing Protocols

   This section is non-normative and is not intended to prejudge a
   solutions framework or any applicability work.  It does, however,
   very briefly serve to note the existence of protocols that could be
   examined for applicability to serve in realizing the model described
   in this document.

   The general principle of protocol reuse is preferred over the
   invention of new protocols or additional protocol extensions, and it
   would be advantageous to make use of an existing protocol that is
   commonly implemented on network nodes and is currently deployed, or
   to use existing computational elements such as PCEs.  This has many
   benefits in network stability, time to deployment, and operator

   It is recognized, however, that existing protocols are unlikely to be
   immediately suitable to this problem space without some protocol
   extensions.  Extending protocols must be done with care and with
   consideration for the stability of existing deployments.  In extreme
   cases, a new protocol can be preferable to a messy hack of an
   existing protocol.

Top      Up      ToC       Page 37 
5.1.  BGP-LS

   BGP - Link State (BGP-LS) is a set of extensions to BGP, as described
   in [RFC7752].  Its purpose is to announce topology information from
   one network to a "northbound" consumer.  Application of BGP-LS to
   date has focused on a mechanism to build a TED for a PCE.  However,
   BGP's mechanisms would also serve well to advertise abstract links
   from a server network into the abstraction layer network or to
   advertise potential connectivity from the abstraction layer network
   to the client network.

5.2.  IGPs

   Both OSPF and IS-IS have been extended through a number of RFCs to
   advertise TE information.  Additionally, both protocols are capable
   of running in a multi-instance mode either as ships that pass in the
   night (i.e., completely separate instances using different address
   spaces) or as dual instances on the same address space.  This means
   that either OSPF or IS-IS could probably be used as the routing
   protocol in the abstraction layer network.

5.3.  RSVP-TE

   RSVP-TE signaling can be used to set up all TE LSPs demanded by this
   model, without the need for any protocol extensions.

   If necessary, LSP hierarchy [RFC4206] or LSP stitching [RFC5150] can
   be used to carry LSPs over the server network, again without needing
   any protocol extensions.

   Furthermore, the procedures in [RFC6107] allow the dynamic signaling
   of the purpose of any LSP that is established.  This means that when
   an LSP tunnel is set up, the two ends can coordinate into which
   routing protocol instance it should be advertised and can also agree
   on the addressing to be said to identify the link that will be

5.4.  Notes on a Solution

   This section is not intended to be prescriptive or dictate the
   protocol solutions that may be used to satisfy the architecture
   described in this document, but it does show how the existing
   protocols listed in the previous sections can be combined, with only
   minor modifications, to provide a solution.

Top      Up      ToC       Page 38 
   A server network can be operated using GMPLS routing and signaling
   protocols.  Using information gathered from the routing protocol, a
   TED can be constructed containing resource availability information
   and Shared Risk Link Group (SRLG) details.  A policy-based process
   can then determine which nodes and abstract links it wishes to
   advertise to form the abstraction layer network.

   The server network can now use BGP-LS to advertise a topology of
   links and nodes to form the abstraction layer network.  This
   information would most likely be advertised from a single point of
   control that made all of the abstraction decisions, but the function
   could be distributed to multiple server network edge nodes.  The
   information can be advertised by BGP-LS to multiple points within the
   abstraction layer (such as all client network edge nodes) or to a
   single controller.

   Multiple server networks may advertise information that is used to
   construct an abstraction layer network, and one server network may
   advertise different information in different instances of BGP-LS to
   form different abstraction layer networks.  Furthermore, in the case
   of one controller constructing multiple abstraction layer networks,
   BGP-LS uses the route target mechanism defined in [RFC4364] to
   distinguish the different applications (effectively abstraction layer
   network VPNs) of the exported information.

   Extensions may be made to BGP-LS to allow advertisement of Macro
   Shared Risk Link Groups (MSRLGs) (Appendix B.1) and the
   identification of mutually exclusive links (Appendix B.2), and to
   indicate whether the abstract link has been pre-established or not.
   Such extensions are valid options but do not form a core component of
   this architecture.

   The abstraction layer network may operate under central control or
   use a distributed control plane.  Since the links and nodes may be a
   mix of physical and abstract links, and since the nodes may have
   diverse cross-connect capabilities, it is most likely that a GMPLS
   routing protocol will be beneficial for collecting and correlating
   the routing information and for distributing updates.  No special
   additional features are needed beyond adding those extra parameters
   just described for BGP-LS, but it should be noted that the control
   plane of the abstraction layer network must run in an out-of-band
   control network because the data-bearing links might not yet have
   been established via connections in the server network.

Top      Up      ToC       Page 39 
   The abstraction layer network is also able to determine potential
   connectivity from client network edge to client network edge.  It
   will determine which client network links to create according to
   policy and subject to requests from the client network, and will take
   four steps:

   -  First, it will compute a path across the abstraction layer

   -  Then, if support of the abstract links requires the use of
      server network LSPs for tunneling or stitching and if those LSPs
      are not already established, it will ask the server layer to set
      them up.

   -  Then, it will signal the client-edge-to-client-edge LSP.

   -  Finally, the abstraction layer network will inform the client
      network of the existence of the new client network link.

   This last step can be achieved by either (1) coordination of the
   end points of the LSPs that span the abstraction layer (these points
   are client network edge nodes) using mechanisms such as those
   described in [RFC6107] or (2) using BGP-LS from a central controller.

   Once the client network edge nodes are aware of a new link, they will
   automatically advertise it using their routing protocol and it will
   become available for use by traffic in the client network.

   Sections 6, 7, and 8 discuss the applicability of this architecture
   to different network types and problem spaces, while Section 9 gives
   some advice about scoping future work.  Section 10 ("Manageability
   Considerations") is particularly relevant in the context of this
   section because it contains a discussion of the policies and
   mechanisms for indicating connectivity and link availability between
   network layers in this architecture.

6.  Application of the Architecture to Optical Domains and Networks

   Many optical networks are arranged as a set of small domains.  Each
   domain is a cluster of nodes, usually from the same equipment vendor
   and with the same properties.  The domain may be constructed as a
   mesh or a ring, or maybe as an interconnected set of rings.

   The network operator seeks to provide end-to-end connectivity across
   a network constructed from multiple domains, and so (of course) the
   domains are interconnected.  In a network under management control,
   such as through an Operations Support System (OSS), each domain is
   under the operational control of a Network Management System (NMS).

Top      Up      ToC       Page 40 
   In this way, an end-to-end path may be commissioned by the OSS
   instructing each NMS, and the NMSes setting up the path fragments
   across the domains.

   However, in a system that uses a control plane, there is a need for
   integration between the domains.

   Consider a simple domain, D1, as shown in Figure 19.  In this case,
   nodes A through F are arranged in a topological ring.  Suppose that
   there is a control plane in use in this domain and that OSPF is used
   as the TE routing protocol.

                           |              D1 |
                           |      B---C      |
                           |     /     \     |
                           |    /       \    |
                           |   A         D   |
                           |    \       /    |
                           |     \     /     |
                           |      F---E      |
                           |                 |

                    Figure 19: A Simple Optical Domain

   Now consider that the operator's network is built from a mesh of such
   domains, D1 through D7, as shown in Figure 20.  It is possible that
   these domains share a single, common instance of OSPF, in which case
   there is nothing further to say because that OSPF instance will
   distribute sufficient information to build a single TED spanning the
   whole network, and an end-to-end path can be computed.  A more likely
   scenario is that each domain is running its own OSPF instance.  In
   this case, each is able to handle the peculiarities (or, rather,
   advanced functions) of each vendor's equipment capabilities.

Top      Up      ToC       Page 41 
                  ------     ------     ------     ------
                 |      |   |      |   |      |   |      |
                 |  D1  |---|  D2  |---|  D3  |---|  D4  |
                 |      |   |      |   |      |   |      |
                  ------\    ------\    ------\    ------
                         \    |     \     |    \     |
                          \------    \------    \------
                          |      |   |      |   |      |
                          |  D5  |---|  D6  |---|  D7  |
                          |      |   |      |   |      |
                           ------     ------     ------

                Figure 20: A Mesh of Simple Optical Domains

   The question now is how to combine the multiple sets of information
   distributed by the different OSPF instances.  Three possible models
   suggest themselves, based on pre-existing routing practices.

   o  In the first model (the area-based model), each domain is treated
      as a separate OSPF area.  The end-to-end path will be specified to
      traverse multiple areas, and each area will be left to determine
      the path across the nodes in the area.  The feasibility of an
      end-to-end path (and, thus, the selection of the sequence of
      areas and their interconnections) can be derived using
      hierarchical PCEs.

      This approach, however, fits poorly with established use of the
      OSPF area: in this form of optical network, the interconnection
      points between domains are likely to be links, and the mesh of
      domains is far more interconnected and unstructured than we are
      used to seeing in the normal area-based routing paradigm.

      Furthermore, while hierarchical PCEs may be able to resolve this
      type of network, the effort involved may be considerable for more
      than a small collection of domains.

   o  Another approach (the AS-based model) treats each domain as a
      separate Autonomous System (AS).  The end-to-end path will be
      specified to traverse multiple ASes, and each AS will be left to
      determine the path across the nodes in that AS.

      This model sits more comfortably with the established routing
      paradigm but causes a massive escalation of ASes in the global
      Internet.  It would, in practice, require that the operator use
      private AS numbers [RFC6996], of which there are plenty.

Top      Up      ToC       Page 42 
      Then, as suggested in the area-based model, hierarchical PCEs
      could be used to determine the feasibility of an end-to-end path
      and to derive the sequence of domains and the points of
      interconnection to use.  But just as in the area-based model, the
      scalability of this model using a hierarchical PCE must be
      questioned, given the sheer number of ASes and their

      Furthermore, determining the mesh of domains (i.e., the inter-AS
      connections) conventionally requires the use of BGP as an
      inter-domain routing protocol.  However, not only is BGP not
      normally available on optical equipment, but this approach
      indicates that the TE properties of the inter-domain links would
      need to be distributed and updated using BGP -- something for
      which it is not well suited.

   o  The third approach (the Automatically Switched Optical Network
      (ASON) model) follows the architectural model set out by the ITU-T
      [G.8080] and uses the routing protocol extensions described in
      [RFC6827].  In this model, the concept of "levels" is introduced
      to OSPF.  Referring back to Figure 20, each OSPF instance running
      in a domain would be construed as a "lower-level" OSPF instance
      and would leak routes into a "higher-level" instance of the
      protocol that runs across the whole network.

      This approach handles the awkwardness of representing the domains
      as areas or ASes by simply considering them as domains running
      distinct instances of OSPF.  Routing advertisements flow "upward"
      from the domains to the high-level OSPF instance, giving it a full
      view of the whole network and allowing end-to-end paths to be
      computed.  Routing advertisements may also flow "downward" from
      the network-wide OSPF instance to any one domain so that it can
      see the connectivity of the whole network.

      Although architecturally satisfying, this model suffers from
      having to handle the different characteristics of different
      equipment vendors.  The advertisements coming from each low-level
      domain would be meaningless when distributed into the other
      domains, and the high-level domain would need to be kept
      up to date with the semantics of each new release of each vendor's
      equipment.  Additionally, the scaling issues associated with a
      well-meshed network of domains, each with many entry and exit
      points and each with network resources that are continually being
      updated, reduces to the same problem, as noted in the virtual link
      model.  Furthermore, in the event that the domains are under the
      control of different administrations, the domains would not want
      to distribute the details of their topologies and TE resources.

Top      Up      ToC       Page 43 
   Practically, this third model turns out to be very close to the
   methodology described in this document.  As noted in Section 6.1 of
   [RFC6827], there are policy rules that can be applied to define
   exactly what information is exported from or imported to a low-level
   OSPF instance.  [RFC6827] even notes that some forms of aggregation
   may be appropriate.  Thus, we can apply the following simplifications
   to the mechanisms defined in [RFC6827]:

   -  Zero information is imported to low-level domains.

   -  Low-level domains export only abstracted links as defined in this
      document and according to local abstraction policy, and with
      appropriate removal of vendor-specific information.

   -  There is no need to formally define routing levels within OSPF.

   -  Export of abstracted links from the domains to the network-wide
      routing instance (the abstraction routing layer) can take place
      through any mechanism, including BGP-LS or direct interaction
      between OSPF implementations.

   With these simplifications, it can be seen that the framework defined
   in this document can be constructed from the architecture discussed
   in [RFC6827], but without needing any of the protocol extensions
   defined in that document.  Thus, using the terminology and concepts
   already established, the problem may be solved as shown in Figure 21.
   The abstraction layer network is constructed from the inter-domain
   links, the domain border nodes, and the abstracted (cross-domain)

                                                       Abstraction Layer
      --             --    --             --    --             --
     |  |===========|  |--|  |===========|  |--|  |===========|  |
     |  |           |  |  |  |           |  |  |  |           |  |
   ..|  |...........|  |..|  |...........|  |..|  |...........|  |......
     |  |           |  |  |  |           |  |  |  |           |  |
     |  |  --   --  |  |  |  |  --   --  |  |  |  |  --   --  |  |
     |  |_|  |_|  |_|  |  |  |_|  |_|  |_|  |  |  |_|  |_|  |_|  |
     |  | |  | |  | |  |  |  | |  | |  | |  |  |  | |  | |  | |  |
      --   --   --   --    --   --   --   --    --   --   --   --
          Domain 1             Domain 2             Domain 3
     Key                                                   Optical Layer
       ...  Layer separation
       ---  Physical link
       ===  Abstract link

                Figure 21: The Optical Network Implemented
                   through the Abstraction Layer Network

Next Section