One document matched: draft-beeram-ccamp-gmpls-uni-bcp-00.txt
CCAMP Working Group V.Beeram
Internet Draft I.Bryskin
Intended status: Standards Track W.Doonan
ADVA Optical Networking
J.Drake
G.Grammel
Juniper Networks
Manuel Paul
Ruediger Kunze
Deutsche Telekom
Expires: April 21, 2012 October 21, 2011
GMPLS-UNI BCP
draft-beeram-ccamp-gmpls-uni-bcp-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 21, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Beeram, et al Expires April 21, 2012 [Page 1]
Internet-Draft
GMPLS-UNI BCP October 2011
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/license-
info) in effect on the date of publication of this document. Please
review these documents carefully, as they describe your rights and
restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License
text as described in Section 4.e of the Trust Legal Provisions and
are provided without warranty as described in the Simplified BSD
License.
Abstract
This document pools together the best current practices that are
being used to apply the GMPLS Overlay model at the User-Network
Interface (UNI) reference point (as defined in [G.8080])
Table of Contents
1. Introduction...................................................2
2. Multi-Layered Approach.........................................3
3. Traffic Engineering............................................4
3.1. Augmenting the Client-Layer Topology......................6
3.1.1. Virtual TE Links.....................................7
3.2. Macro SRLGs...............................................7
3.3. Switching Constraints.....................................8
4. Connection Setup...............................................9
5. Security Considerations........................................9
6. Normative References...........................................9
7. Acknowledgments...............................................10
1. Introduction
Generalized Multiprotocol Label Switching (GMPLS) provides tools to
create end-to-end services in various transport technologies. These
tools can be used to support service management in different types
of deployment models. RFC 4208 discusses how GMPLS can be applied to
the overlay model. There are a good number of implementations that
have built on the basic concepts discussed in RFC 4208 and have
successfully demonstrated interoperability. This document is an
attempt to pool together the best current practices that are being
used to apply the GMPLS Overlay model at the User-Network Interface
(UNI) reference point (as defined in [G.8080]).
Beeram, et al
Expires April 21, 2012 [Page 2]
Internet-Draft
GMPLS-UNI BCP October 2011
RFC 4208 recommends the use of hierarchical service activation when
GMPLS is used for the core network - this document takes this
concept further, discusses the notion of "augmenting the client-
layer TE topology" and explains how this augmentation enables
client-layer networking in an overlay model. The concepts discussed
in this document are based primarily on experiences drawn from
interoperating GMPLS-enabled IP routers with Optical Transport
elements.
2. Multi-Layered Approach
When an end-to-end service crosses a boundary between two regions of
dissimilar transport technology, it is necessary to execute distinct
forms of service activation within each region.
Fig 1: Sample Hybrid Topology
(See PDF version)
For example, in the hybrid network illustrated in Fig 1,
provisioning a transport service between two GMPLS-enabled IP
routers on either side of the optical WDM transport topology
requires operations in two distinct layer networks; the client-layer
network interconnecting the routers themselves, and the server-layer
network interconnecting the optical transport elements in between
the routers.
Activation of the end-to-end service begins with a path
determination process, followed by the initiation of a signaling
process from the ingress along the determined path, per the set of
figures shown in Fig2.
Fig 2: Hierarchical Service Action
(See PDF version)
Beeram, et al
Expires April 21, 2012 [Page 3]
Internet-Draft
GMPLS-UNI BCP October 2011
3. Traffic Engineering
The previous section outlines the basic method for activating end-
to-end services across a multi-layer network. As a necessary part
of that process an initial path selection process was performed,
whereby an appropriate path between the desired endpoints was
determined through some means. Further, per expectations set
through current practices with regard to service provisioning in
homogeneous networks, operators expect that the underlying control
plane system will provide automated mechanisms for computing the
desired path or paths between network endpoints.
In particular, operators do not expect under normal circumstances to
be required to explicitly specify the end-to-end path; rather,
operators expect to be able to specify just the endpoints of the
path and rely on an automated computational process to identify and
qualify all the elements and links on the path between them. Hence
when operating a hybrid network such as that described in Fig 1, it
is necessary to extend existing traffic engineering and path
computation mechanisms to operate in a similar manner.
Path computation and qualification operations occur at the path
computation element (PCE) selected by ingress element of an end-to-
end service. In order to be able to compute and qualify paths, the
PCE must be provided with information regarding the traffic
engineering capabilities of the layer network to which it is
associated with, in particular what the topology of the layer
network is and what layer-specific transport capabilities exist at
the various nodes and links in that topology.
It is important to note that topology information is layer-specific;
e.g. path computation and qualification operations occur within a
given layer, and hence information about topology and resource
availability are required for the specific layer to which the
connection belongs to. The topology and resource availability
information required by elements in the client-layer is quite
distinct from that required by the elements in the server-layer
network. Hence, the server-layer traffic engineering links are of no
importance for the client-layer network, and it is actually
desirable to block their advertisements into the client TE domain by
the server-layer border nodes.
Beeram, et al
Expires April 21, 2012 [Page 4]
Internet-Draft
GMPLS-UNI BCP October 2011
In the sample hybrid network (Fig 1) there are multiple optical
transport elements supporting the connection between the GMPLS-
enabled IP routers, and hence the physical topology between them
includes several nodes and links. However, the optical elements
between the IP routers are not able to switch traffic within the
client-layer network of routers (e.g. IP/MPLS), as the optical
elements are lambda switches, not IP/MPLS switches. Hence while the
intervening optical elements may physically exist along the path,
they are not a part of the topology available to the IP/MPLS routers
for the purposes of traffic engineering in the client-layer network.
An example of what the client-layer Traffic Engineering topology
would look like for the sample hybrid network is shown in the top
half of Fig 3.
Fig 3: Traffic Engineering - ERO with "loose hop"
(See PDF version)
In this example, the TE topology associated with the client-layer
network is indicated by nodes [A, B, C, D, E, F, I, J] and links [A-
F, E-B, J-C, I-D], whereas the TE topology associated with the
server-layer network is indicated by nodes [E, F, G, H, I, J] and
links [E-G, F-G, F-H, G-H, G-J, H-I, H-J, I-J]. The border nodes
[E, F, I, J] at the core are visible in both the topologies.
In this example, if the "B" router attempts to determine a path to
the "D" router it will be unable to do so, as the client-layer
topology to which the B and D routers is connected does not include
a full client-layer path between them. The only way to setup an end-
to-end path in this case is to use an ERO with a "loose hop" across
the server-layer domain as illustrated in Fig 3. This would cause
the server-layer to create the necessary segment of the client-layer
topology on the fly. However, this approach has a few drawbacks -
[a] the necessity for the operator to specify the ERO with the
"loose" hop; [b] potential sub-optimal usage of server-layer network
resources; and [c] unpredictability with regard to the fate-sharing
of the new segment (that is created on the fly) with other links of
the client-layer topology.
In order to be able to compute a full path between the two client-
layer endpoints, the client-layer topology must be sufficiently
augmented to indicate where there are paths through the server-layer
topology which can provide transport to services in the client-layer
Beeram, et al
Expires April 21, 2012 [Page 5]
Internet-Draft
GMPLS-UNI BCP October 2011
topology. In other words, in order for a client to compute path(s)
across the server-layer domain to other clients, the segment of the
client-layer topology over the server-layer domain should be pre-
planned and made available (in terms of TE links and nodes that
exist in the client-layer) to all the clients. This is discussed in
detail in the next section.
3.1. Augmenting the Client-Layer Topology
In the example hybrid network, consider a scenario where each GMPLS-
enabled IP router is connected to the optical WDM transport network
via a transponder. Further consider the situation where the
transponder at node F can be connected to the transponder in node J
via the optical pathway F-G-H-J. A WDM connection can be provisioned
in the server-layer along this path, and then advertised as a TE
link in the client-layer. With the availability of this link, the
path computation function at node A is able to compute an end-to-end
path from A to C.
Fig 4: Traffic Engineering - End to End Path Computation
(See PDF version)
In this case, in order for the TE link to be made available in the
client-layer topology, the network resources corresponding to the
underlying server-layer connection must be fully provisioned
beforehand.
As another example, consider a network configuration where the
transponders at nodes E, F, J and I are connected to each other via
directionless ROADM components. It is physically possible to
connect any transponder to any other transponder in the network. As
there are transport capabilities available in the server-layer
network between every element containing an adaptation function to
the client-layer network, the operator in this case would not wish
to reserve any network resources in the server-layer until the setup
of the client-layer connection is initiated. The next section
proposes a method to cater to this particular operational
requirement.
Beeram, et al
Expires April 21, 2012 [Page 6]
Internet-Draft
GMPLS-UNI BCP October 2011
3.1.1. Virtual TE Links
A "Virtual TE Link" is defined as a TE link that is advertised into
the client-layer, with available but unreserved resources in the
server-layer necessary to bring up the connection that supports that
TE link. In other words, "Virtual TE Links" represent specific
transport capabilities available in the server-layer network which
can support services in the client-layer network. The two
fundamental properties of a Virtual TE Link are: [a] It is
advertised just like a real TE link and thus contributes to the
buildup of the client-layer topology (and thus client-layer elements
see no difference between virtual and real links); and [b] It does
not require allocation of resources at the server-layer until used,
thus allowing the sharing of server-layer resources with other
virtual TE links.
Fig 5: Traffic Engineering - End to End Path Computation (w/
"Virtual TE Links"
(See PDF version)
In the example shown in Fig 5, the availability of a lambda channel
along the path F-G-H-J results in there being a virtual traffic
engineering link between F and J within the client-layer topology.
With the availability of this link, the path computation function at
node A is able to compute an end-to-end path from A to C.
When a virtual TE link gets selected and signaled in the ERO of the
client-layer connection, it ceases to be "Virtual" and transforms
into a regular TE-link. When this transformation takes place, the
clients will notice the change in the advertised available bandwidth
of this TE-link. Also, all other Virtual TE links that share
resources with the TE-link in question start advertising "zero"
available bandwidth. Likewise, the TE network image reverts back to
the original form as soon as the last client-layer connection, going
through the TE link in question, is released.
3.2. Macro SRLGs
The TE links that are added to the client-layer topology cannot be
assumed to be totally independent. It is quite possible for a given
TE link to share the same fate with one or more other TE link(s).
This is because the underlying server-layer connections (real or
potential) can traverse the same server-layer link and/or node, and
Beeram, et al
Expires April 21, 2012 [Page 7]
Internet-Draft
GMPLS-UNI BCP October 2011
failure of any such shared link/node would make all such connections
inoperable (along with the client-layer links they serve). If
diverse end-to-end client-layer connections are to be computed, the
fate-sharing information of the TE links needs to be accounted for.
The standard way of addressing this problem is to use SRLGs as a
part of TE link advertisements.
A traditional SRLG represents a shared physical network resource
upon which normal function of a link depends. Such SRLGs can also be
referred to as physical SRLGs. Zero, one or more physical SRLGs
could be identified and advertised for every TE link in a given
layer network. However, there is a scalability issue with physical
SRLGs in multi-layer environments. For example, if a WDM layer
connection serves an IP layer link, every WDM link and node
traversed by the connection must be considered as a separate SRLG.
The number of SRLGs to be advertised to client (e.g. IP) layer per
link would be directly proportional to the number of hops traversed
by the underlying server-layer connection.
The notion of Macro SRLGs addresses this scaling problem. Macro
SRLGs have the same protocol format as that of their physical
counterpart and can be assigned automatically for each TE link that
is advertised into the client-layer as a result of the existence of
an underlying server-layer connection (instantiated or otherwise). A
Macro SRLG represents a set of shared path segments that are
traversed by two or more of the underlying server-layer connections.
Each shared path segment can be viewed as a sequence of shared
resources where each individual resource has a physical SRLG
associated with it (example depicted in Fig 6). The actual procedure
for deriving these Macro SRLGs is beyond the scope of this document.
Fig 6: Macro SRLGs
(See PDF version)
3.3. Switching Constraints
Certain types of optical network configurations necessitate the
specification of connectivity constraints in the TE advertisements.
If the switching constraints associated with the binding between the
TE link served by the server domain and its associated access TE
link do not get advertised, there is a risk of an invalid path being
picked (Fig 7). This document recommends the use of the extensions
specified in [GEN_CNSTR] to address this.
Beeram, et al
Expires April 21, 2012 [Page 8]
Internet-Draft
GMPLS-UNI BCP October 2011
Fig 7: Switching Constraints
(See PDF version)
4. Connection Setup
Experience with control plane operations in multi-layer networks
indicates there are benefits to coordinating certain signaling
operations, in the following manner. Consider the scenario where the
core is a WDM network comprising of ROADMs. The set-up time for a
service at the optical layer can be fairly long, as it can involve
time-consuming power-equalization procedures, amongst other layer-
specific operations. This means that at very least, the setup timers
for the client-layer service would need to be somehow coordinated
with that of the server-layer service. To avoid this operationally
awkward issue, a phased connection setup process as depicted in Fig
8 is proposed.
Fig 8: Phased Connection Setup
(See PDF version)
As long as the server-layer connection is not completely "UP" (for
example: Fully Power Equalized), the nodes at the edge of the core
would signal the client-layer PATH/RESV messages with the T
(Testing) bit set in the ADMIN_STATUS. The T bit would be cleared in
these messages only after the underlying server-layer connection is
deemed fully operable.
5. Security Considerations
TBD
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4208] G. Swallow, J.Drake, H. Ishimatsu, and Y. Rekhter,
"GMPLS UNI: RSVP-TE Support for the Overlay Model",
RFC 4208, October 2005.
Beeram, et al
Expires April 21, 2012 [Page 9]
Internet-Draft
GMPLS-UNI BCP October 2011
7. Acknowledgments
TBD
Authors' Addresses
Vishnu Pavan Beeram
ADVA Optical Networking
Email: vbeeram@advaoptical.com
Igor Bryskin
ADVA Optical Networking
Email: ibryskin@advaoptical.com
Wes Doonan
ADVA Optical Networking
Email: wdoonan@advaoptical.com
John Drake
Juniper Networks
Email: jdrake@juniper.net
Gert Grammel
Juniper Networks
Email: ggrammel@juniper.net
Manuel Paul
Deutsche Telekom
Beeram, et al
Expires April 21, 2012 [Page 10]
Internet-Draft
GMPLS-UNI BCP October 2011
Email: Manuel.Paul@telekom.de
Ruediger Kunze
Deutsche Telekom
Email: Ruediger.Kunze@telekom.de
Beeram, et al
Expires April 21, 2012 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 07:54:50 |