[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-many-ccamp-srg-01.txt
We would like to post the following updated draft
on "Inter domain routing with Shared Risk Groups".
We requested a time slot to present the draft at
CCAMP WG in Salt Lake City IETF.
Your comments are welcome.
Regards,
sudheer
CCAMP Working Group S. Dharanikota, R. Jain (Nayna)
Internet Draft D. Papadimitriou (Alcatel)
Document: draft-many-ccamp-srg-00.txt R. Hartani (Caspian Networks)
Category: Internet Draft G. Bernstein (Ciena)
Expires: June 2002 V. Sharma (Metanoia)
C.Brownmiller, Y.Xue (Worldcom)
December 2001
Inter-domain routing with Shared Risk Groups
draft-many-ccamp-srg-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
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
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 [2].
Abstract
This document discusses how inter-domain routing using Shared Risk
Group (SRG) may be used for computing diverse paths, and also
discusses the extensions that we propose for routing (and eventually
signaling) protocols. The concepts proposed in this document are
useful to provide the requested intelligent control plane for multi-
layered networks.
Internet Draft – CCAMP Working Group – Expires January 2002
1
draft-many-ccamp-srg-01.txt December 2001
1. Introduction
For many years in the telecommunications industry, the concept of
SRLG (Shared Risk Link Group) has been used for computing a path
that is disjoint from a set of links sharing the same risk. For this
purpose, links sharing the same risk are grouped together to have
the same SRLG value. When two links (or more) share the same risk,
it means that when one link fails the other(s) can fail
simultaneously. Reference [IETF-DIMITRI-SRLG] provides enhancements
to the concept of SRLGs thereby streamlining its meaning.
Networks are planned to recover from failures due to a risk
(represented by an SRLG) using different mechanisms, which we call
capabilities. So if we look at SRLG on a positive note we may want
to intentionally use the capabilities supported in the network due
to an SRLG. For example one may provide a 1:1 shared link protection
(link capability) for many connections using the link that has an
SRLG value of X.
A risk sharing, however, is not limited to links, which has been the
case until now in a majority of the IETF proposals (e.g., [IETF-
KIREETI-OSPF]). In this document, we extend the applicability of
SRLGs to path (or connections) included in a domain, where we define
a domain to be a group of resources (nodes and links) that provide
similar capabilities and that share the same set of risk(s). For
example a domain can be consecutive set of links that has 1:1 link
level protection or a set of links that form a ring or a protected
Forwarding Adjacency (FA) in a domain. Note that in such a scenario
(for example in ring topology), a failure will affect all the other
resources in the domain. This observation parallels the notion of
what SRLG for a link to an SRG (Shared Risk Group) for a domain.
The “shared risk concept” can also be viewed as a mechanism to hide
or reduce the amount of topology information propagated in a multi-
layered network. Consider a multi-layered network with fiber,
optical (for instance G.709 OTN), SONET/SDH and router topology in
the ascending order of encompassing the previous topology. In such a
topology a link at the client layer (for example, router level) can
mean many nodes and links in the server layer (for example,
SONET/SDH, optical and fiber level). Hence to provide diversity at
the client layer link level one should consider failures in the
server layer topology. Thus, to provide diverse links or paths
(sequences of links) at the client layer requires some means of
abstracting the diversity at the server layer, so that this
abstraction can be used by path computation at the client layer. At
present the only way to provide this abstraction of the server layer
topology in the client layers is to use SRLG. With the adoption of
GMPLS (Generalized Multi-Protocol Label Switching) control plane in
the packet and circuit based networks it is now possible to compute
diverse paths in multiple layers. The notion of diversity can be
abstracted and dynamically computed at many layers. In this
document, we concentrate on the risk associated with a sequence of
Internet Draft - CCAMP Working Group – Expires June 2002 2
draft-many-ccamp-srg-01.txt December 2001
disjoint elements (unlike in case of SRLG). The procedures of doing
such a complex task is provided in this document.
The following observations serve as a basis for considering the
extension of the “Shared risk” concept to more than just a link:
@
The number of nodes or links that are affected by a failure is
dependent on the physical topology of the network (or the server
layer(s) topology in a multi-layered network).
- A typical node failure may also represent the failure of set
of links, or multiple link failures or SRLGs.
-
On the other hand, a failure of a fiber (or a group of
fibers) may result in the failure of multiple logical links.
The abstraction of the capability of a domain can be useful in
- Summarizing the information propagated in the routing
protocols,
- Hiding the topology of the domain for the sake of loose path
specification Computing diverse paths by concatenating the
capabilities of the domains.
- Hiding the topology details of the server layers in a multi-
layered network (if needed).
@
Sharing risk is opposite to capability of a domain, which is a
required parameter for service provisioning by ISPs.
- Establishing a primary path disjoint from the secondary one at
the same layer reduces the chances of losing traffic or
dropping traffic for longer time. - Such a notion enables more
factual based risk assessment and hence helps in achieving
risk reduction by improving incremental topological design.
2. Requirements and Applicability
As mentioned in [OIF-CARRIER-REQ] and [IPO-JOHN-IMP], the diversity
compromises between two links being used for routing should be
defined in terms of Shared Risk Link Groups (SRLGs), a group of
links which share some resource, such as a specific sequence of
fiber ducts or a specific office. A SRLG is a relationship between
the resources that should be characterized by two parameters:
@
Type of Compromise: Examples would be shared fiber cable, shared
conduit, shared ROW, shared link on an optical ring, shared
office - no power sharing, etc.)
- Support for hierarchical SRLG allocation
- Support for logical level and physical level diversity
- Support for computing diverse path computation over multi-
layered networks
- Support for hiding lower-layer capability in the upper layers
- Extent of Compromise: For compromised outside plant, this would
be the length of the sharing.
Internet Draft - CCAMP Working Group – Expires June 2002 3
draft-many-ccamp-srg-01.txt December 2001
Consequently, the mechanisms proposed in this must be applicable
when: :
@
To achieve constraint based path computation in a multi-layered
network with integrated control plane and reduction in the amount
of TE (Traffic Engineering) parameters.
@
To hide the topology in a tiered network (whether control planes
overlay or peer-to-peer) with a single or multiple administrators
to the domain(s).
@
To reduce the amount of TE information propagated by localizing
the scope of information propagation and hence distribution of
the path computation.
@
To propose mechanisms that are applicable to packet and non-
packet oriented networks (multi-service networks) in the scope of
GMPLS architecture independently of the path provisioning state.
Some of possible business applications that can be solved with the
concepts of SRG are protected path provisioning, preferably routed
circuit provisioning and preferred quality circuit provisioning.
4. Definitions and scope
4.1. Definition of risk domain
Definition: A “risk domain” is a group of arbitrarily connected
nodes and links that together can provide certain like-capabilities
(such as a chain of dedicated/shared protected links and nodes, or a
ring forming nodes and links, or a protected FA).
This is advertised in the routing protocols as “risk domain link”,
an abstract point-to-multipoint link. It is rather advisable not
advertising this as NBMA link to avoid the complexity of the
designated router. This solution does not, however, preclude
handling of the risk domain concept via a representation as a NBMA
link.
Another way to see the risk domain link is as a Forwarding Adjacency
(FA – refer to [IETF-KIREETI-FA]) if and only if source and
destination are located within the same area and can have a pre-
established path between them with the same capabilities in all the
links through which this FA is passing through.
In the current document, we assume a risk domain is part of a
routing (OSPF or ISIS) area. From now on, we use the term domain
interchangeably with risk domain.
4.2. Definition of SRG
Definition: An SRG (a 32 bit integer) represents the risk domains’
capabilities and other parameters, which assist in computing diverse
Internet Draft - CCAMP Working Group – Expires June 2002 4
draft-many-ccamp-srg-01.txt December 2001
paths through the domain and in assessing the risk associated with
the risk domain.
With the observations made in section 1 and the introduction of the
concept of a risk domain, we define the notion of a “Shared Risk
Group” (SRG) per risk domain.
Note that the SRLGs of this risk domain are a subset of the SRGs.
SRLGs address only risks associated with the links (physical and
logical) and locations within the risk domain, whereas SRGs contains
nodes and other topological information in addition to links. The
key difference between an SRLG and an SRG is that an SRLG translates
to only one link share risk with respect to server layer topology
(even FA and virtual links) while an SRG translates a sequence of
SRLGs (including nodes) over the same layer from one source to one
or more than one destination located within the same area.
4.3. Scope
The following are the goals of this work:
- Diversity:
@
To capture link, node and domain-level diversity with minimal
TE information.
@
Summarizable SRG notation, which decreases the complexity of
computing disjoint paths.
@
Propose a mechanism that works for both single and multi-
layered networks, which use Generalized MPLS distributed
control plane. In the first version of the document we
consider only intra-AS networks with single layer topology. In
the future version we will generalize the mechanism to inter-
AS and multi-layered architectures.
- Risk:
@
Assign capabilities to the SRGs such Resource Class, TE
Metric, etc.
@
Assign failure probability to the SRGs, which, in turn, enable
the “evaluation” of the probabilities corresponding to the
risk assessment.
@
Facilitate path computation against a given risk type. This
case will be handled in the future versions of the document.
- Other:
@
SRLG is currently a flat 32 bit number in a given autonomous
system. The notion of SRG will help in localization of SRLG
allocation and hence helps in summarization.
@
Deployment (i.e., operational aspects) of a SRLG or SRG
capable network.
5. Extensions
5.1. Configuration
The configuration parameters considered are the following:
Internet Draft - CCAMP Working Group – Expires June 2002 5
draft-many-ccamp-srg-01.txt December 2001
Domain boundary configuration [Mandatory]: This is the configuration
of domain to provide a boundary for summarization or hiding the
capability information, as will be elaborated in the next few
sections. This is in parallel to the concept of an area boundary in
the existing IGPs.
Hierarchical SRLG configuration [Optional]: The hierarchical SRLG
configuration is provided by the SRLG encoding itself. In [IETF-
DIMITRI-SRLG], the SRLG are encoded as a Resource Location and a
Resource Identifier. The latter includes a list of type – SRLG
identifier fields. This concept helps in localizing SRLG allocation,
hiding the server layer link level topology and in reducing amount
of server layer TE information propagation.
Domain to SRG allocation [Mandatory]: Grouping of nodes and links
that provide certain capability will have an SRG allocated to it.
The SRG value can be a flat 32-bit number or can represent some of
the domain capabilities. The SRG encoding will be discussed in the
future versions of the document. The node ID from which the point-
to-multipoint virtual link starts identifies the SRG allocation.
This means that the root of the virtual point-to-multipoint link
defines the SRG allocation.
Per SRG capability allocation [Mandatory]: The capabilities of the
domain such as protection and restoration can be assigned per
domain. Please note that the likeness of these capabilities across
the domain is a requirement for a link or a node to be part of the
domain. Other link related parameters that can be extended to SRG
such as TE Metric (additive metric), Resource Class (ON/OFF), etc
could be also allocated per SRG.
Capability to risk factor parameters [Optional]: Risk associate with
a domain depends on the protection and restoration mechanisms
inherent to the domain and that can be achieved through the
capabilities of the domain. Since the risk domain belongs to a
single operator, we can assign these parameters per mechanism per
domain. This can be assigned per type of failure per SRG.
Preferred path allocation parameters [Optional]: This is the weight
associated to the SRG. This weight can be assigned statically
configured once at the initial stage or dynamically determined since
it can be defined as additive metric whose individual values are the
link TE metrics.
5.2. Encoding
A hierarchical encoding mechanism is the key to the summarization
process of the SRLGs of a given server layer link. This encoding can
be performed on the physical and logical resources as elaborated in
[IETF-DIMITRI-SRLG]. SRG on the other hand represents a both the
nodes and the links, which can take the same hierarchical encoding
Internet Draft - CCAMP Working Group – Expires June 2002 6
draft-many-ccamp-srg-01.txt December 2001
as in SRLG, but in the current version of the document we assume it
to be a 32-bit flat number with the capabilities being specified as
TLVs.
5.3. Capability assignment
Refer to [IETF-GMPLS-ARCH] to get the complete list of the link
capabilities that can be propagated. Here we envision at least the
protection related capabilities can be extended to the domain level,
in addition we have few more parameters, which assist in the risk
assessment, as discussed below.
- Capability assignment (will be elaborated further in the later
versions of the document): This is assigned to each of the SRG,
which is propagated in the opaque LSA in the routing protocols
and assists in the diverse path computation and risk assessment.
@
Domain capability: Extensions similar to link capabilities as
noted by [IETF-GMPLS-ARCH]. These include shared or dedicated
protection capabilities of the links in the domain.
@
Node capability: Extensions similar to link capabilities as
noted by [IETF-GMPLS-ARCH].
@
Link capability: Extensions as discussed by [IETF-GMPLS-ARCH].
@
Conditional probability for risk: This provides the operator
assigned risk factor for a given SRG. This can be carried per
type of failure.
5.4. Routing protocol extensions
5.4.1. Propagation of a domain link
A network administrator groups a set of links and nodes of similar
capabilities into a domain and assigns an SRG to the domain. A
physical topology can have overlapping domains if links and/or nodes
participating in the domain notion support multiple capabilities.
A domain is represented as an abstract point-to-multipoint link for
the sake of representation, and for path computation in the routing
protocols. As discussed before, this can represent any type of
physical topology represented under the abstract notion of domain.
The exact semantics of the domain link opaque LSA [RFC 2370]
(defined as an opaque LSA of Type 10) is presented in below. The
scope of this opaque LSA can be link, area or AS specific.
5.4.1.1. Opaque LSA Payload
The Opaque LSA payload consists of one or more nested
Type/Length/Value (TLV) structures. The format of the Opaque LSA TLV
structure is defined as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Internet Draft - CCAMP Working Group – Expires June 2002 7
draft-many-ccamp-srg-01.txt December 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length (in bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.4.1.2 SRG TLV
The SRG TLV includes the SRG ID (32 bits identifier).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD) | Nx4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// . . . //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the TLVs other than the risk factor TLV is available in
the IGP extensions as available now in the IETF drafts such as
[IETF-GMPLS-OSPF], [IETF-GMPLS-ISIS]. In the future versions of this
document we will elaborate on the other required TLVs specific to
this document. Note that even the protection related TLVs would be
specified per SRG (unlike per link in the case of regular networks).
5.4.2. Path computation
Path computation becomes very rich with this concept with the
concept of the loose nodes and links being represented by the risk
domain concept. A dynamic path computation mechanism can use the
concatenation of the domains to compute the loose explicit path,
leaving the expansion of the loose segments to the domain border
nodes.
First we start with one domain “computation” and then expand it.
Here below some guidelines:
- Pruning of SRG that do not belong to the same resource class
- Exclude all the resources already selected for other LSP using
that SRG for the same VPN ID, same source node ID, etc.
- Exclude all the resources already selected for the same
restoration group of LSP (case of edge-to-edge protection)
- Take the explicit inclusive and exclusive requirements into
consideration
- In the remaining topology, prune all links with insufficient
capacity to route the current LSP route demand.
Internet Draft - CCAMP Working Group – Expires June 2002 8
draft-many-ccamp-srg-01.txt December 2001
Compute the shortest path in the remaining network. If no route is
found, the LSP setup request fails and the LSP setup is rejected.
6. Security Considerations
Security considerations related to SRLG Inference model and its
applications are left for further study.
7. Conclusions
In this document we presented the concept of a risk domain
abstracting nodes and links with like-capabilities. This notion can
be used very effectively for inter-domain routing by reducing the
amount of TE information to be carried. We proposed a mechanism
called SRG to capture this information and assist in diverse path
computation and risk assessment in single and multi-layered
networks.
8. Acknowledgments
The authors acknowledge John Strand for his discussions, which lead
to many of the features supported by the SRG concept.
9. References
[IETF-KIREETI-TE] K. Kompella et al., “OSPF Extensions in Support of
Generalized MPLS,” draft-kompella-ospf-gmpls-extensions-01.txt, IETF
draft (work in progress).
[IETF-DIMITRI-SRLG] D. Papadimitriou et al., “Inference of Shared
Risk Link Groups,” draft-many-inference-srlg-00.txt, IETF draft
(work in progress).
[IETF-JOHN-IMP] J. Strand et al., “Impairments and other constraints
on optical Layer routing,” draft-ietf-impairments-00.txt, IETF draft
(work in progress).
[IETF-SRLG-PROTO-EXT] S. Dharanikota et al., “Inter domain routing
with SRGs – Protocol extensions,” draft-many-ccamp-srg-00.txt, IETF
draft (work in progress).
[IETF-GMPLS-ARCH] E. Mannie et al., “Generalized Multi-Protocol
Label Switching (GMPLS) Architecture,” draft-many-gmpls-
architecture-00.txt, IETF draft (work in progress).
[OIF-CARRIER-REQ] J. Strand et al., “Carrier Optical Services
Framework and Associated Requirements for UNI,” OIF2000.155, OIF
carrier group document.
Internet Draft - CCAMP Working Group – Expires June 2002 9
draft-many-ccamp-srg-01.txt December 2001
[IETF-KIREETI-FA] K. Kompella, Y. Rekhter, “LSP Hierarchy with MPLS
TE,” draft-ietf-mpls-lsp-hierarchy-02.txt, IETF Working group
document.
[IETF-GMPLS-OSPF] [IETF-OPT-OSPF] Kireeti Kompella et al., “OSPF
Extensions in Support of Generalized MPLS,” draft-kompella-ospf-
gmpls-extensions-01.txt, IETF working group draft.
[IETF-GMPLS-ISIS] Kireeti Kompella et al., “IS-IS Extensions in
Support of Generalized MPLS,” draft-ietf-isis-gmpls-extensions-
02.txt, IETF working group draft.
[RFC 2370] R. Coltun, “The OSPF opaque LSA option,” RFC 2370.
10. Author's Addresses
Sudheer Dharanikota: sudheer@nayna.com
Raj Jain: raj@nayna.com
Dimitri Papadimitriou: dimitri.papadimitriou@alcatel.be
Riad Hartani: riad.hartani@caspiannetworks.com
Greg Bernstein: gregb@ciena.com
Vishal Sharma: v.sharma@ieee.org
Curtis Brownmiller: curtis.brownmiller@wcom.com
Yong Xue: yxue@uu.net
John Strand: jls@research.att.com
Internet Draft - CCAMP Working Group – Expires June 2002 10
draft-many-ccamp-srg-01.txt December 2001
Appendix A: Diversity and SRG
A brief introduction is provided to the need for diversity to set
the stage for the rest of the discussion. Traffic engineering in IP
(Internet Protocol) networks is achieved using MPLS technology as an
overlay on the IP networks. The success of the MPLS TE concept has
lead to its application in the optical domain as well. The “pinned”
or connection-oriented nature of LSPs reduces the capability of IP
traffic to recover automatically from failures in the data path. To
achieve path resiliency, therefore, diverse paths must be
established between the source and destination MPLS nodes through
the use of explicit routing (loose or strict). By introducing the
connection-oriented (LSPs) in the IP technology, we loose the
automatic hop-by-hop recovery of the data paths in case of failures.
Hence, diverse paths are established between the source and
destination MPLS nodes for achieving path resiliency.
The diversity requirements of transport networks have some
differences with those of router (Layer 3 and Layer 2 switching)
networks. They are mainly:
@
Transport networks provide elaborate protection and restoration
mechanisms,
@
Transport topologies are not always structured in mesh topologies
(agreed but in fact an OCh on top of an OMS SPRing for instance
appears as a point-to-point connection at the OCh level so that
Ring topology does not necessarily mean ringed connection, as
assumed by the router networks, and
@
Transport-level protection and restoration mechanisms are not
considered in the diverse path computation by the MPLS technology
(at least till now) dynamic path computation constructs.
Diversity in the router world is achieved as follows:
- Request: Given the (physical and logical) topology, link
capabilities, and constraints to calculate 1 to N diverse path
between two points in the network.
- Input:
@
Topology:
. Physical topology is always meshed and multiplexed (fiber,
cables, segments etc.).
. Areas and autonomous systems achieve logical topology.
@
Capability:
. Only link capabilities are propagated.
@
Constraints:
. Inclusive requirements: Such as a preferred links (color).
. Exclusive requirements: Such as avoiding a node (node-
level diversity, link-level diversity).
. Limiting requirements: Such as bandwidth.
- Output:
@
Paths available or not.
Internet Draft - CCAMP Working Group – Expires June 2002 11
draft-many-ccamp-srg-01.txt December 2001
@
If paths are available then provide the strict or loose
paths.
. Strict paths can be provided if the physical topology is
known between the source and destination.
. Loose paths are provided if the end-to-end physical
topology is not known.
Diversity in the router + transport world may be achieved as
follows:
@
Request: Given the (physical and logical) topology, link
capabilities, domain capabilities and constraints to calculate 1
to N diverse paths between two points in the network.
@
Input:
@
Topology:
. Physical topology is flexible (Rings, Meshes, Ring-Mesh inter
connected).
. Domains (or islands) are used to achieve logical topology.
@
Capability:
. Both link (or span) and domain capabilities need to be
propagated.
@
Constraints:
. Inclusive requirements: Such as preferred links and preferred
link, node and domain capabilities.
. Exclusive requirements: Such as avoiding a link, node or
domain.
. Limiting requirements: Such as bandwidth.
@
Output:
@
Paths available or not.
@
If paths are available then provide the strict or loose paths.
. Strict paths can be provided if the physical topology is
known between the source and destination – not necessarily I
can provide an strict routed SDH L-LSP while being aware of
the lambda topology but not on the fiber or duct topology.
. Loose paths are provided if the end-to-end physical topology
is not known or cannot be interpreted such as in ring
topologies or would like to leave to the risk domain to
decide (for local optimization or due to lack of information
or to reduce TE information flooding) – not necessarily for
instance inter-area routing can be loose even if the local
source area physical topology is known.
Discussion:
The following observations can be made between the diverse path
setup mechanisms in the router world and in the transport world:
- Sharing risk is not only a property of the links, but it can be
extended to nodes and domains. Thus, an SRG can be associated
with the links, nodes, and even domains.
Internet Draft - CCAMP Working Group – Expires June 2002 12
draft-many-ccamp-srg-01.txt December 2001
- Also, for example, domain capabilities can be associated with the
domain SRG to achieve inclusive constraints. For example, a BLSR
ring can have an SRG with ring capabilities associated with it.
As a precursor to achieving such constraints we propose to extend
the SRLG notion to represent logical topologies. By assigning SRGs
in a hierarchical fashion (to a region, a zone/domain and a node),
we can capture the capabilities, and risks, associated with them. An
extensive discussion on this subject is provided in [IETF-DIMITRI-
SRLG].
Considering the above practical knowledge of real world scenarios,
it is essential (to reduce the computation time) to reduce the
number of SRLGs by means of some encoding. We observe that the
amount of configuration can also be reduced (for example, from 100s
of SRLGs on a Trans-Atlantic link). This poses the following
requirements:
- Need a mechanism to encode (and hence summarizable) SRLG to group
represent a link or node or domain wide individual SRGs.
- Need to modify the path computation algorithms (such as CSPF) for
accommodating the new encoding scheme.
- Need to enhance the path computation mechanisms to work with the
logical topologies (or domains).
- Need to propagate the logical topologies (or domains) via the
routing protocols.
Internet Draft - CCAMP Working Group – Expires June 2002 13
draft-many-ccamp-srg-01.txt December 2001
Appendix B: Risk assessment and SRG
Risk (the complementary of availability) assessment is defined as
the evaluation of the potential risk associated with the inclusion
of a given resource (this resource belongs to a given resource type
located within a given logical structure such as a geographical
location) in a given path.
A brief discussion for the motivation of the risk assessment
capabilities of SRLG is provided here. Consider the following
example, where the client device makes the following requests to the
optical network:
- Request (either through signaling protocols or using an SLA) for
a persistent connection with 99.999 % (widely known 5 9s) of
availability or equally a down time less than X minutes per year.
- Request a high-protection for a portion of the traffic (at the
expense of paying a higher charge) compared to other low-priority
traffic.
Such requirements will be translated into constraints in path
computation. Such constraints can be grouped into path selection
constraints and path characterization constraints.
- Path selection constraints:
These typically dictate which physical path should be taken to
achieve the client’s availability requirements. These
requirements are typically the logical and physical diversity.
- Path characterization constraints:
Path characterization requirements typically dictate the
protection mechanisms as requested by the client. This can be
achieved in the form of optical rings, meshed protection
mechanisms, etc. These constraints can be used in using the link,
node, and domain capabilities as discussed in the previous
section on diversity.
The components that need formalization in this example are:
- Step 1. Specification of the user requirements (such as the
example above), which need to be translated into “network
constraints”.
- Step 2. Configuring the network in a way that helps in assessing
its features, such as the availability
- Step 3. Propagating the information thus configured.
- Step 4. Using information thus propagated in path computation.
Step 1 of specifying the requirements is not in the scope of this
document. Steps 2 - 4 are discussed below.
Internet Draft - CCAMP Working Group – Expires June 2002 14
draft-many-ccamp-srg-01.txt December 2001
Discussion:
A convenient way to achieve risk assessment is by associating a
conditional risk value with each of the SRLGs and SRGs, as discussed
in [IETF-DIMITRI-SRLG]. Also, by associating a weight factor with
the SRG, we can increase the choice of selecting specific SRGs. This
calls for configuring:
- A Risk factor per SRG
- A Weight factor per SRG
In addition to the SRG capabilities, discussed before, the above
values can also be propagated via routing protocols. These routing
requirements are discussed in the following section.
With the help of the above two configuration parameters, the use of
typical CSPF algorithms to compute a path can be extended to assess
the risk associated with the path. For example, if a path traverses
SRGs 1, 3, 5, then one may infer that the risk associated with this
path is (Risk 1 x Risk 3 x Risk 5).
Internet Draft - CCAMP Working Group – Expires June 2002 15
draft-many-ccamp-srg-01.txt December 2001
Full Copyright Notice
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Internet Draft - CCAMP Working Group – Expires June 2002 16
begin:vcard
n:Dharanikota;Sudheer
tel;work:408-956-8000 x357
x-mozilla-html:FALSE
url:http://www.cs.odu.edu/~sudheer
org:Nayna Networks Inc.;CTO's office
version:2.1
email;internet:sudheer@nayna.com
title:Network Architect
adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;;
fn:Sudheer Dharanikota
end:vcard