Internet Engineering Task Force Cristel Pelsser
INTERNET DRAFT FUNDP
Olivier Bonaventure
UCL
October 2002
Expires April, 2003
RSVP-TE extensions for interdomain LSPs
<draft-pelsser-rsvp-te-interdomain-lsp-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
We propose extensions to RSVP-TE to allow the establishment of
traffic engineered LSPs with fast restoration requirements. We first
discuss the problem of
establishing explicitly routed interdomain LSPs and show that the
current subobjects found in RSVP-TE are not sufficient to establish
interdomain LSPs because they do not take into account the policy
constraints of the interdomain environment. We then show how to
extend the fast-reroute and detour objects to protect interdomain
links and ASBRs on interdomain LSPs. We also discuss the
establishment of disjoint interdomain LSPs for restoration and load
balancing purposes in the appendix. Finally, we describe the
necessary RSVP objects and flags and discuss the impact of the
proposed solution on the syntax of existing RSVP-TE objects and the
syntax of new required objects are presented.
Pelsser FORMFEED[Page 1]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
1 Introduction
Today, most of the work on MPLS has focussed on its utilization
inside a single domain. When considering traffic engineering, most of
the existing solutions with MPLS assume that the domain is organized
as a single IGP area. Interarea traffic engineering with MPLS is
still an open problem.
In addition to MPLS-based traffic engineering inside a single area,
there are several other important applications of MPLS that are not
limited to a single domain. A first application is that a domain
organised as a BGP confederation could be interested in using MPLS
for traffic engineering and fast restoration purposes accross is
subASes. This is not possible with the existing protocols. A second
application are the MPLS-based VPNs that cross interdomain
boundaries. In this case, interdomain LSPs need to be setup between
domains. Given the reliability and performance requirements of VPNs,
it can be expected that those interdomain LSPs will need to be
traffic engineered and will require fast restoration in case of
failures. Given the large BGP restoration time, a solution based only
on BGP would not meet the requirements of the VPN users. A third
application is the utilization of MPLS to establish virtual peerings
through inter-AS LSPs. An example of virtual peerings with MPLS is
given by the MPLS-IX architecture presented in [NEN02]. A fourth
application is the establishment of optical LSPs that may cross
interdomain boundaries [ea01].
This document is organized as follows. We first discuss the problem
of establishing explicitly routed interdomain LSPs and show that the
current subobjects found in RSVP-TE are not sufficient to establish
interdomain LSPs because they do not take into account the policy
constraints of the interdomain environment. We then look at the
possibility of protecting segments of interdomain LSPs. We consider
the protection of interdomain links and ASBRs since links and
routers inside an AS may be protected by techniques exposed in
[PGS^+02].The protection of these resources requires extensions to
the detour object from [PGS^+02] and the introduction of a new
object. Other extensions to the PCS protocol introduced in [VIZ^+02]
are left for further work. We also discuss the establishment of
disjoint interdomain LSPs for restoration and load balancing purposes
in the appendix. Finally, we describe the necessary RSVP objects and
flags and discuss the impact of the proposed solution on the syntax
of existing RSVP-TE objects and the syntax of new required objects
are presented.
2 Establishment of inter-domain LSP
Pelsser FORMFEED[Page 2]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
To setup an intradomain Label Switched Path (LSP), or an intradomain
LSP segment, with RSVP-TE, the initiating Label Switching Router
(LSR) needs to know the destination of the LSP. The destination of
the LSP is either known through the Interior Gateway Protocol (IGP),
as a BGP Next Hop, or by manual configuration. The initiating LSR
computes a strict or a loose path towards the destination of the LSP
depending on the topology information flooded by the IGP. If the
domain is divided into areas, the initiating LSR may not be able to
compute a strict route toward the destination since it only
possesses limited information concerning the topology of the other
areas in the domain. But, when the domain only consists of one area,
a strict route may be computed. Even when it is possible to compute
a strict route, a loose route may be computed instead, depending on
manual configuration.
The situation is different when considering interdomain LSPs. In this
case, the source of the LSP tunnel does not know the detailed
interdomain topology. It only possesses information given by the IGP,
concerning the domain to which it belongs, and the interdomain routes
distributed by BGP. Therefore, it cannot determine precisely the path
of the LSP all the way to the AS destination. This is not a problem
because the Explicit Route Object (ERO) may be updated by
intermediate LSRs on the way of the Path message. It follows that
the source of the tunnel may be able to specify the path toward the
next area or the next domain. Routing inside the area or the domain
will be based on the ERO. A loose route may be given for the rest of
the path. The border router will then compute, eventually based on
the ERO, the route for the next area (domain) and update the ERO.
Another problem to consider in the dynamic establishment of
interdomain LSPs is that the tunnel source usually does not know the
IP address of the remote tunnel end point before establishing the
tunnel. Based on its BGP routing table, the source of the LSP only
has information about the destination prefixes and their AS paths.
And, the remote end points of dynamically established interdomain
LSPs cannot be configured manually since the need for such LSPs may
not be known in advance. For routing purposes, the prefix
information is much more useful than the AS path information, but
the AS path information can be used to build an ERO object for the
interdomain LSP.
To solve the problem of the remote tunnel end point address, we
propose to enable the establishment of LSPs based on a prefix or on
an AS number and a prefix. For the establishment of an LSP based on
a prefix destination,
the Path message should be forwarded through the network until it
reaches an LSR that has an IP address that is part of this prefix.
The Path message itself will be routed on the basis of its
Pelsser FORMFEED[Page 3]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
destination IP prefix and possibly along an explicit route defined by
an ERO object.
The second type of destination that we propose is composed of two
parts : an AS number and an IP prefix. In this case, the Path
message should be forwarded through the network on the basis of the
destination prefix until it reaches an LSR that is part of the
specified AS. The path followed by the Path message can also
optionally be specified with an ERO object.
Figure 1 shows the difference between a Path message with an AS plus
prefix and a Path message with a prefix destination. When the
destination of the Path message is an AS number, the node initiating
the LSP chooses a prefix inside the AS destination and routing of
the path message is based on the chosen prefix. Once a node inside
the AS destination is reached the Path message stops, independently
of the prefix used for routing purposes. A Path message with a
prefix destination, is routed on the basis of this prefix. The Path
message stops once it reaches a node inside the specified prefix.
Figure may be found in the postscript version [PB02] of this draft
Figure 1: Establishment of LSP with AS+prefix or prefix destination
Another issue to consider concerns the refresh messages. For the
first Path message, we have proposed to use the AS+prefix or prefix
destinations. These destination types are necessary to send the
first Path message. However, once the first Resv message is received,
the source LSR of the LSP knows the IP address of the destination
LSR. A possible solution in this case would be to establish a new
interdomain LSP with the found destination IP address and to cancel
the establishment of the LSP with the AS+prefix or AS destination.
However, this would mean that two LSPs with different identifiers
are first established before tearing off the one with prefix or AS
destination. This is not desirable and could create problems like
multiple reservations of the same resources. Tearing down the LSP
established with a prefix or AS destination before establishing the
LSP with the corresponding IP destination address does also not
ensure the final establishment of the LSP since the needed resources
may meanwhile be allocated to other LSPs. To avoid these problems, a
new object containing the identifier of the first Path message could
be inserted into the first following refresh message. This object
will be used to identify the path-state of the LSP and update it with
the new identifier based on the now known remote tunnel end-point.
This solution requires that the new Session object types,
corresponding to AS+prefix and prefix destinations, be supported by
all intermediate nodes as well as the object used to store the
Pelsser FORMFEED[Page 4]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
original identifier of the LSP which contains a prefix or an AS
destination. We do not opt for this solution since, in addition to
the required support of new objects, a method is needed to determine
when the initial identifier does not need to be transmitted inside
Path refresh messages to face the non reliability in the
transmission of RESV messages. A last proposal, would be not to add
any new types of Session objects. A prefix destination is then
represented by an IP address terminated by zeros. Additionally, a
subobject representing the prefix destination is inserted at the end
of the ERO and a flag indicates that there is no need to establish
the LSP beyond the first node belonging to the prefix subobject.
Once a node that belongs to the last subobject in the ERO is
reached, the Path message is ended and a Resv message is sent
upstream. In the case of an AS destination, the Session object is
also an IP address that is set to the prefix, used for routing the
Path message, followed by zeros. And, the last subobjects of the ERO
are the number of the AS destination and the prefix used for routing
purposes with a flag indicating that the Path message is ended once
a node belonging to the AS is reached. The AS number subobject is
inserted to ensure that the AS destination is reached before
terminating the Path message once the prefix subobject is treated. In
this last proposal, all subsequent Path refresh messages will carry
the same Session object. The identifier of the LSP will be carried
in all those messages allowing a router to access the path-state of
the corresponding LSP. This solution does not affect the Session
object that must be supported by all routers along the path of the
LSP.
2.1 Processing of the ERO and RRO objects
We expect that across interdomain boundaries, the ERO object will be
often used to specify a strict or loose path for the LSPs being
established. This object is often used in combination with the RRO
object for route pinning purposes. Inside a single AS, the following
situation typically occurs. The source LSR creates a new LSP with a
loose ERO object and an RRO object. Once the LSP is established, the
source LSR receives an RRO object with the complete list of the IP
addresses of the LSRs traversed by this LSP. With this RRO object,
the source LSR can then easily create a new strict ERO object that
will be used to pin the route of the established LSP. The RRO object
also enables the source LSP to compute a node disjoint LSP from the
primary LSP. Furthermore, both the ERO and RRO objects are used to
detect loops an LSP.
However, in the interdomain case, we must take care about
transparency issues that do not occur inside a single AS. The two
main problems are that the interdomain routing protocol does not
distribute the detailed Internet topology and that an AS may not
Pelsser FORMFEED[Page 5]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
want to reveal its topology. For this reason, an AS may not agree to
reveal the detailed path followed by an LSP by propagating the RRO
object to external peers. To meet this transparency requirement while
still being able to support route pinning, disjoint path computation
and loop detection, we propose changes to the processing of the
Record Route Object (RRO) at the AS border routers.
Figure may be found in the postscript version [PB02] of this draft
Figure 2: Establishment of an interdomain LSP
Figure 2 illustrates the establishment of an inter-domain LSP. In
this case, router R0 determines that it needs to establish an LSP
toward AS3. It selects a prefix that belongs to AS3 and creates a
Path message with the destination set to the chosen prefix. The last
subobject in the ERO represents the chosen prefix and the previous
subobjects contains AS3 AS number. When R1 receives this Path
message, it selects an interdomain path that verifies the
constraints that may be optionally specified inside the Path message
[VIZ^+02]. Then, it inserts the computed path inside the ERO and
stores the ERO in the path-state. When receiving the Path message, R3
checks if it belongs to the first abstract (1) node in the ERO.
Then, it computes an appropriate route inside AS1, based on the
constraints, since it cannot reach AS3 directly. It updates the ERO
by inserting the computed route segment. Finally, it stores the
modified ERO in its path-state and forwards the Path message to the
next abstract node in the ERO. R4 then removes its address from
the ERO and forwards the Path message to R7. Similarly, R7 forwards
the Path message to R8. And, finally, R8 is the LSP endpoint. The
destination of the tunnel is reached because R8 belongs to AS3 that
is specified as the
destination for the LSP since the last subobject of the ERO is
marked as only being used for routing purposes.
To support the transparency requirements for inter-domain LSPs,
changes are required to the processing of the RRO object. This
object may be part of the Path and Resv messages. It allows to
record the addresses of the intermediate LSRs along the path of an
LSP with, optionally, the labels used along this path. As said
previously, certain ASs may not want to let other ASs know their
internal topology. Therefore, when using the RRO for interdomain
LSPs, some information should be removed from the RRO before
crossing AS boundaries. For this, we propose to allow AS boundary
routers to summarize the path inside their AS as three elements :
the IP address of the entry point, the AS number and the IP address
of the exit point. This will allow us, as shown later, to support
loop detection, route pinning and the establishment of disjoint
LSPs.
Pelsser FORMFEED[Page 6]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
To support the transparency requirements of ASs, we propose to modify
the processing of the RRO object by the AS boundary routers (ASBRs).
We do not change anything to the routers that are not ASBRs. To be
able to hide topology information of an AS, the last router inside an
AS, i.e. the exit point, needs to be able to determine the
information that has to be aggregated. This may be done by parsing
the RRO, in the reverse order, to determine for each subobject if it
belongs to the current AS. This solution implies a non-negligible
amount of processing. Therefore, it is interresting to mark inside
the RRO the first router inside the current AS when inserting the
corresponding subobject.. Hence, changes to the RRO processing are
also required at the first router inside the AS, i.e. the entry
point. When a Path/Resv message with RRO object enters an AS, the
router stores its address with a flag, indicating that it is the
entry point, inside the RRO. The exit point then removes the RRO
subobjects starting after the last subobject marked with the ``entry
ASBR'' flag. This set of subobjects is replaced by the current AS
number and the exit point address. It follows that the AS topology
information is summarized into the entry point inside the AS, the AS
number and the address of the exit point. All routers along the LSP
store the RRO once they added their address as in [ABG^+01]. An
illustration of the processing of the RRO object is given in figure
3, where R3 is the ingress ASBR of AS1 and R7 is the egress ASBR of
AS1.
Figure may be found in the postscript version [PB02] of this draft
Figure 3: Processing of the RRO object
We notice that for a correct summarization of the RRO object, both
the ingress and egress ASBR must support the modified processing of
the RRO object. The insertion of the AS number inside the RRO
object, when aggregation is performed, requires the definition of a
new subobject for the RRO object. In addition to this new AS
subobject, it might also be useful to change the IPv4 address and
IPv6 address subobjects into IPv4 and IPv6 prefixes.
With our proposed solution, route pinning can be supported as
follows. The RRO object stored in the path-state of an LSR is used
to build the ERO of subsequent Path messages. Therefore, the RRO
must be used in both Path and Resv messages to obtain a complete
information about the path inside the AS and about the interdomain
path. The source of the tunnel sets the ERO of the Path refresh
messages to the RRO stored in its path-state. Once this Path message
reaches the entrance of the next AS, the RRO of the path inside this
AS is placed inside the ERO. This will force the Path refresh
messages to follow the same path as the initial Path message inside
the AS. This method is also valid for the downstream ASs because the
ERO will be updated in a similar manner at the border of each AS.
Pelsser FORMFEED[Page 7]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
Figure 4 illustrates the processing of the RRO object for route
pinning purposes.
Figure may be found in the postscript version [PB02] of this draft
Figure 4: Establishment of an interdomain LSP with route pinning
Another utilization of the RRO object occurs in loop detection. This
utilization is still possible with our proposed solution. The routers
on the path of an LSP possess the RRO in their path-state with
aggregated information concerning the path inside other ASs and
detailed path inside the current AS. The loop detection will be
performed at two different levels. The routers inside an AS will be
responsible to detect intradomain loops by verifying that their
address does not appear twice in the RRO. On the other hand, the
ASBR will be responsible for the detection of interdomain loops. To
detect such loops the ASBR verifies that its AS number is not
already included inside the RRO object of a received RSVP message.
This is possible since the summarization scheme that we propose for
the RRO object has replaced all the IP addresses of a given AS by the
entry/exit points and the AS number.
3 Protection of inter-domain LSPs
In this section, we discuss how the previous extensions can be used
to provide protection of inter-domain links and protection of AS
border routers. We will also refine the objects from [PGS^+02] that
are needed for SRLG protection and the required features of a Path
Computation Server (PCS) and the communication protocol used with
these PCSs. The solution we discuss requires the head-end LSR, of the
LSP to protect, to indicate the required type of protection by using
the appropriate flags inside the session attribute object of the path
message. For example, it specifies that either link or node
protection is required. Then, the downstream LSRs establish Detour
LSPs or rely on Bypass tunnels, which may as well protect entire
path segments, according to the protection policy of each AS.
We also consider the provision of SRLG protection. In order to
indicate that SRLG protection is required, a flag inside the session
attribute object or the fast reroute object [PGS^+02] is required.
Moreover, a flag is needed inside the RRO IP address/prefix
subobjects to indicate if SRLG protection is provided.
A way to provide end-to-end protection of interdomain LSPs is given
in appendix A
Before looking at the details of the proposed solution, it is useful
to repeat the terminology defined in earlier documents [PGS^+02,
SH02] .
Pelsser FORMFEED[Page 8]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
1. Link protection is provided by using a backup LSP that
does not cross the link to be protected.
2. Node protection is provided by using a backup LSP that
does not utilize neither the node to be protected nor
the upstream link going to this node on the primary
path (2).
3. Point of Local Repair (PLR) The head-end of a backup
tunnel or a detour LSP[PGS^+02].
4. Path Switch LSR (PSL) An LSR that is responsible for
switching or replicating the traffic between the
working path and the recovery path [SH02].
5. Path Merge LSR (PML) An LSR that is responsible for
receiving the recovery path traffic, and either
merging the traffic back onto the working path, or, if
it is itself the destination, passing the traffic on
to the higher layer protocols [SH02].
6. Detour LSP A Detour LSP provides one-to-one
protection. A single LSP is established to protect
another single LSP.
7. Bypass tunnel A Bypass tunnel provides many-to-one
protection. It consists of a single tunnel that
backups a set of protected LSPs by making use of label
stacking[PGS^+02].
8. NHOP Bypass Tunnel A backup tunnel which bypasses a
single link of the LSP to be protected [PGS^+02]. Such
Bypass tunnel is used to protect the bypassed link.
9. NNHOP Bypass Tunnel A backup tunnel which bypasses a
single node of the LSP to be protected [PGS^+02].
NNHOP Bypass Tunnels protect against the avoided node
failure and its upstream link.
Before considering in the next sections the various types of
protection schemes in details, it is useful to summarize the main
problems that arise when considering interdomain LSP protection
compared to intradomain LSP protection. In both cases, each segment
of the LSP to be protected will be protected through the utilization
of a protection LSP that could be a Detour LSP or a Bypass tunnel
established between the PLR and the PML. Of course, to be useful,
this protection LSP needs to be disjoint from the segment of the
primary LSP that it protects. Inside a single domain (organized as a
single IGP area), each node on the path followed by a primary LSP
knows the detailed path followed by this LSP and the complete
topology of the domain distributed by a link-state IGP. Based on this
information, the PLR can determine a path for a protection LSP that
needs to be disjoint from a given segment of a primary LSP.
Across interdomain boundaries, the situation is more complex because
the LSRs on the path of a primary LSP do not have such detailed
Pelsser FORMFEED[Page 9]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
information about the LSP and the interdomain network topology. As
discussed in section 2, even with the utilization of the RRO and ERO
objects, a typical LSR will only know the list of transit AS, the IP
addresses of the entry and exit ASBR inside each AS and the path
followed by the LSP inside its own domain. Due to the incompleteness
of the information about the path followed by a primary LSP inside
an external domain, a LSR may have difficulties in locating the PML
of interdomain LSPs. Since the PLR and the PML are located in
different AS, we expect that the PLR will not be able to determine
the address of the PML for interdomain LSPs. Instead the address of
the PML will have to be determined by LSRs inside the downstream AS.
A second issue to be considered is the establishment of the
protection LSPs. Inside its own domain, a LSR knows the entire
network topology provided that the IGP is configured as a single
area. However, the same LSR will only receive summarized information
via BGP about the available interdomain paths. A single LSR will not
usually be able to compute an explicit path for an interdomain backup
LSP that needs to be disjoint from a segment of an existing LSP. The
path to be followed by a backup interdomain LSP will be computed by
several LSRs based on the information known by each LSR. This implies
that a mechanism to communicate between LSRs will be required. For
this, we rely on the mechanism described in [VIZ^+02]. The
extensions required to [VIZ^+02] are left for further studies.
3.1 Link protection with a Detour LSP
In this section, we study the utilization of a Detour LSP to provide
link protection for an inter-domain link. Our reference environment
is shown in figure 5. Assume that a primary LSP is being established
between R11 inside AS1 and R23 inside AS2 and that the interdomain
link between R13 and R21 needs to be protected by a Detour LSP. In
this case, R13 will act as the PLR. To establish the Detour LSP, this
LSR will need to obtain several informations as shown in figure 5.
Figure may be found in the postscript version [PB02] of this draft
Figure 5: Link protection with Detour LSP
First, the PLR needs to determine which disjoint interdomain link can
be used to reach the downstream AS on the path of the primary LSP. We
assume that at least two disjoint links exist between each pair of AS
on the path followed by a primary LSP (3). To determine the usable
interdomain links, the PLR can rely either on :
1. manual configuration. In this case, the PLR would know
by configuration that link R12-R22 should be used to
protect link R13-R21. Since a typical AS will usually
Pelsser FORMFEED[Page 10]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
only have a small number of external links towards a
given AS, this can be a valid solution in practice.
2. its BGP Routing Information Base (RIB). Since the PLR
is an ASBR, it receives the routes selected by the
other ASBR via iBGP. It could then parse its BGP RIB to
determine the closest iBGP peer that advertised routes
towards the downstream AS (or more precisely the routes
with the downstream AS as the next-hop in their AS-Path
attribute).
If the Detour LSP needs to be SRLG disjoint from the interdomain link
to be protected, the PLR also needs to obtain information about the
SRLG of the interdomain link. In the case of a manual configuration,
the configuration can easily take the SRLG information into account.
If the PLR relies on the information distributed by iBGP to
determine the suitable interdomain links, then iBGP needs to
distribute the information about the SRLG of each interdomain link.
This could be done, for example, by configuring R12 to advertise
with iBGP a /32 route towards R22 with an AS-Path of AS2 and to
encode the SRLG of the interdomain link between R12 and R22 as a set
of BGP extended communities. This route could be announced with the
well known NO_EXPORT community to ensure that it is not redistributed
across interdomain boundaries. The detailed encoding of the SRLG
inside extended communities is outside the scope of this document.
Instead of distributing the SRLG information with iBGP, another
solution would be to extend the communication protocol defined in
[VIZ^+02] to permit an ASBR to use it to request the SRLG of the
interdomain links of another ASBR.
With this information, the PLR is able to determine the path of the
Detour LSP inside its own AS. If the Detour LSP enters the downstream
AS on the same entry ASBR as the primary LSP (4), then this ASBR can
act as the PML. However, it can be expected that usually the Detour
LSP will enter the downstream AS through a different entry ASBR than
the entry ASBR of the primary LSP. In this case,
the entry ASBR of the Detour LSP has to determine the address of the
LSR where merging with the primary LSP has to be performed.
We expect that the Detour LSP will merge with the primary LSP inside
the AS, but each AS may have its own policy concerning the location
of the PML. Several solutions are possible. A first solution is to
merge the Detour LSP with the primary LSP at the entry ASBR of the
primary LSP (R21 in figure 5). In this case, the address of the PML
is contained inside the summarized RRO of the primary LSP. This
information can be specified by the PLR. A second solution is to
merge the Detour LSP with the primary LSP at the exit ASBR of the
Pelsser FORMFEED[Page 11]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
primary LSP. In this case, the address of the PML may also be found
in the summarized RRO of the primary LSP. A third solution is to
merge the Detour LSP and the primary LSP at the closest LSR from the
entry ASBR of the Detour LSP. In this, case, the entry ASBR of the
Detour LSP needs to obtain the path of the primary LSP to determine
the optimum location of the PML. This can be achieved with some
communication between the entry ASBR of the Detour (R22) and the
entry ASBR of the primary LSP (R21), known through the summarized RRO
of the primary LSP. This communication may be performed through
extensions to the path request and reply messages described in
[VIZ^+02]. These extensions are left for further study.
3.2 Node protection with a Detour LSP
In this section, we discuss the utilization of Detour LSPs to provide
protection of an ASBR and its upstream link. We consider two distinct
situations depending on whether the node to be protected is an exit
or an entry ASBR for the primary LSP.
3.2.1 Node protection of the entry ASBR with a Detour LSP
Figure 6 shows a reference configuration and the information required
at the different LSR to allow the establishment of a Detour LSP to
provide protection of the entry ASBR.
Figure may be found in the postscript version [PB02] of this draft
Figure 6: Node protection of the entry ASBR with a Detour LSP
To be able to establish the Detour LSP, the PLR (R13 in figure 6)
needs to know the following information :
1. the list of ASBRs connected to the downstream AS. This
list may be obtained as discussed section 3.1.
2. the SRLGs of the inter-domain link between R13 and
R21. These SRLGs can be manually configured.
3. the SRLGs of the alternative inter-domain links. This
information can be obtained in discussed in section
3.1.
4. the node to avoid with the Detour LSP This node is
known since it is stored inside the RRO.
Compared with the establishment of a Detour LSP to provide link
protection, the situation is slightly different in the case of node
protection. Here, the PML cannot obviously be the entry ASBR of the
Pelsser FORMFEED[Page 12]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
downstream AS (R21 in figure 6). The entry ASBR on the Detour LSP
will thus need to determine the path towards the PML with the primary
LSP. To compute this path, this ASBR needs to know the following
information :
1. the SRLGs of the inter-domain link between the PLR and
the node to be protected These SRLGs can be obtained
through manual configuration or distributed with iBGP.
It may also be carried inside the Path message of the
Detour LSP. In section B.7, we show how the Detour
object permits to specify SRLGs to avoid.
2. the node to be avoided with the Detour LSP The address
of this node may be stored inside the Detour object
defined in [PGS^+02].
3. the node where merging with the primary has to be done
The PML is obtained by communicating with a Path
Computation Server (PCS) as explained in section 3.1.
3.2.2 Node protection of the exit ASBR with a Detour LSP
To protect a primary LSP from the failure of an exit ASBR, the
situation is slightly more complex. Figure 7 shows a reference
configuration and the information required at the different routers
in order to provide this type of protection for the exit ASBR.
Figure may be found in the postscript version [PB02] of this draft
Figure 7: Node protection of the exit ASBR with a Detour LSP
To protect an exit ASBR, the LSR upstream of the exit ASBR
(R11 on figure 7) needs to be able to determine the path for the
Detour LSP. For this, the PLR needs to find another ASBR inside its
AS that is also connected with the downstream AS. This information
can be obtained through manual configuration or distributed by iBGP
as in the previous cases if the PLR receives routes via iBGP. If the
PLR does not receive BGP routes, then it should communicate with
another LSR to obtain the required information. This could be done
via a dedicated PCS or by using the PCS protocol [VIZ^+02] to
contact the exit ASBR to be avoided.
If the Detour LSP also needs to be SRLG disjoint in addition to being
node disjoint, then the PLR needs to obtain the SRLG information
about the primary and the candidate Detour paths. The SRLGs of the
link that leads to the exit ASBR, on the primary path is obtained
from the conjunction of the information concerning the SRLGs flooded
Pelsser FORMFEED[Page 13]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
by the IGP and the RRO which enables to record the path of the
working LSP. SRLGs of links to join alternative ASBRs connected to
the downstream AS are also known through the IGP. And, the SRLGs of
the alternative interdomain links to reach the downstream AS are
either known by all ASBRs through manual configuration or by all BGP
routers inside the AS through iBGP. Therefore, if the PLR is a BGP
router it may possess the required SRLG information. Otherwise,
communication with a PCS is required to get the SRLGs of the inter-
domain links. Finally, the PLR needs to know the address of the node
to be avoided. This information is stored inside the Detour object
in the Path message of the Detour LSP.
The entry ASBR of the Detour LSP (R22 on figure 7) has to know the
following information in order to complete the establishment of this
LSP.
1. the SRLGs of the link leading to the node to protect
These SRLGs are not available through the IGP and BGP
to this router. Therefore, they should be carried
inside the Path message of the Detour LSP. This is not
currently possible with the Detour object defined in
[PGS^+02]. It follows that either extensions to this
Detour object are required or the new Avoid Route
Object (ARO) (5), specified in section B.3, should be
used to store the SRLGs that should be avoided by the
Detour.
2. the address of the PML If the PML is the entry ASBR on
the primary LSP, then this address is known by at
least the node to be protected. The PLR may known this
information from the summarized RRO and place it inside
the path message used to establish the Detour LSP. A
PCS may also be used to obtain the address of the PML
and the path to reach this PML.
3.3 Link protection with use of a Bypass LSP
Instead of protecting segments of a primary LSP with a dedicated LSP,
in this section, we look at the possibility to protect several LSPs
with a single Bypass tunnel. This kind of protection can be provided
as soon as
the LSPs to protect share a common PLR and downstream node.
In this section, we will first look at the
way a Bypass tunnel is selected in order to provide protection for
an interdomain link. Then, we will look at the establishment of a
Bypass tunnel that is used to protect several primary
Pelsser FORMFEED[Page 14]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
LSPs.
When the protection of an interdomain link is considered, the PLR is
the exit ASBR and, the common downstream router belongs to the
downstream AS. Therefore, it is not easy to determine if different
working LSPs can be protected by the same Bypass tunnel when they do
not have a common entry point inside the downstream AS, since the
path of these LSPs inside other ASs is not known by the PLR.
Figure may be found in the postscript version [PB02] of this draft
Figure 8: Link protection with Bypass tunnel
In the following examples (figures 8, 9,10), we assume that the
primary LSP (``Primary 1'') is already established as well as the
Bypass tunnel that protects the interdomain link (R13-R21). In figure
8, a new LSP toward network 138.48.32/24 is established. This new
LSP is called ``Primary 2''. Link protection needs to be provided
for this LSP. Therefore, the PLR (R13) has to know that a Bypass
tunnel toward the entry ASBR (R21) of the primary LSP inside the
downstream AS (AS2) exists and that it protects against a failure
of the interdomain link R13-R21. Additionally, the PLR (R13) has to
be able to determine if there is enough bandwidth on the Bypass
tunnel to protect the new LSP, if bandwidth protection is required.
Figure may be found in the postscript version [PB02] of this draft
Figure 9: PML identification problem
Figure may be found in the postscript version [PB02] of this draft
Figure 10: PML identification problem
When Bypass tunnels protecting the required interdomain link exist
but do not terminate at an ASBR, it is more complex to determine if
the Bypass tunnel is appropriate to protect the new LSP being
established. In this case, it is not possible for the PLR to know
whether the destinations of established Bypass tunnels are on the
path of the primary LSP.
Figures 9 and 10 illustrate the difficulty of choosing an adequate
Bypass when the PML is not an ASBR. Among the candidate Bypass
tunnels selected by the PLR (here the exit ASBR), some may not be
adequate for the protection of a given LSP as shown on figure 10,
where the PML of the existing Bypass is not on the path of ``primary
2''.
In figure 11, the required information and communication mechanisms
between ASBR are exposed. In order to determine if the candidate
Bypass tunnels for ``Primary 2'', known by the PLR (R13) are suitable
for the protection of this LSP, the PLR needs to communicate with
Pelsser FORMFEED[Page 15]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
the entry ASBRs of the candidate Bypasses inside the downstream AS.
These ASBRs, respectively, have to contact the entry ASBR (R22) of
the LSP to protect, to obtain the path of the primary LSP. With
this information, they will be able to determine the Bypass tunnels
that cross the primary LSP and are usable for the protection of the
working LSP; they will communicate the identifiers of these Bypasses
to the PLR. When the first answer concerning an appropriate Bypass
tunnel arrives, the PLR chooses this Bypass. If no positive answer
is received, the PLR will have to establish a new Bypass tunnel as
described below.
Figure may be found in the postscript version [PB02] of this draft
Figure 11: Choosing adequate Bypass
The question of the establishment of Bypass tunnels has now to be
approached. These tunnels may be manually pre-configured but it is
also interesting to be able to establish these LSPs dynamically. In
this case, when an LSP with link protection required is established
and no Bypass LSP is available for this LSP, a new Bypass can be
established.
The Fast Reroute object defined in [PGS^+02] is still useful in the
set up of an interdomain Bypass tunnel. When a Bypass tunnel may be
used, the ``facility backup desired'' flag is set inside the fast
reroute object. In addition, a similar object to the Detour object
is required in order to indicate the link that has to be avoided by
the Bypass tunnel. This object should have another value for the C-
type field to distinguish between a Bypass and a Detour LSP. If SRLG
disjointness is required, the SRLGs of interdomain links may be
obtained as exposed in section 3.1.
When a Bypass tunnel that protects an interdomain link needs to be
established, the PLR and the entry ASBR of the Bypass tunnel inside
the downstream AS have to get at least the same information as these
routers need to have in order to establish a Detour that protects
the same interdomain link (see figure 5). In addition, the PLR of a
Bypass tunnel has to determine the bandwidth required by the Bypass.
3.4 Node protection with use of a Bypass LSP
In this section, we first interest ourselves in the protection of an
exit ASBR on a working path through a Bypass tunnel. Then, we look
at the protection of entry ASBRs with Bypass tunnels. We first
suppose that the required Bypass tunnel already exists and the PLR
needs to determine the Bypass that it can use. Then, we suppose that
there are no appropriate Bypass already established. In this case,
we look at the establishment of Bypass tunnels that protect against
ASBRs failures.
Pelsser FORMFEED[Page 16]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
A Bypass tunnel can only be used by working paths that share the same
PLR and PML. The PML may be any router inside the downstream AS but
as explained in the previous section, it is easier to determine the
candidate Bypass tunnels when the PML is either the entry or the exit
point inside the downstream AS since this information is known by
looking into the aggregated RRO. In figure 12, upon the
establishment of the second primary LSP (``Primary 2''), the PLR
(R11) has to know the existance of a Bypass that is a good candidate
for the protection of the exit ASBR (R13) as well as SRLG disjoint
from link R11-R13 and that it merges on the path of ``Primary 2''
LSP. If the merging router isn't an ASBR then inter-LSR
communications as the onces shown on figure 11 should take place in
order to determine a suitable Bypass. However, here the LSP that
initiates such communication may not be an ASBR since we consider the
protection of an exit ASBR.
Figure may be found in the postscript version [PB02] of this draft
Figure 12: Bypass node protection
When no candidate Bypass tunnel fits the requirements, a new Bypass
tunnel has to be established. This requires that the PLR (R11)
obtains the same kind of information as listed on figure 7. The
information required at the entry ASBR (R22) for the establishment of
the Bypass tunnel is also represented on figure 7. And, as in
section 3.3, the PLR (R11) additionally has to determine the
bandwidth to be allocated to the Bypass tunnel. The entry ASBR of the
Bypass tunnel in the downstream AS (R22) obtains the SRLGs of the
link that leads to the node to protect through the Bypass object and
gest the address of the PML in the same way as described in section
3.2.
Figure may be found in the postscript version [PB02] of this draft
Figure 13: Bypass node protection
Concerning the protection of an entry ASBR with a Bypass tunnel, no
new mechanism has to be introduced. The PLR needs to know the
existence of a Bypass tunnel that protects the right node and
eventually the SRLG of the link leading to that node. In order to
identify if the candidate Bypass tunnels selected by the PLR merge
on the path of the primary LSP and are disjoint from the primary
LSP, the PLR communicates the identifiers of the selected tunnels
and the resources to be avoided by these tunnels to their entry
point inside the next AS. These ASBRs determine if these Bypass
tunnels are appropriate for the protection of the entry ASBR of the
working path by communicating with the entry ASBR of the LSP to
protect in
order to obtain the path and the SRLGs of this working path. An
example of the selection of a Bypass tunnel suitable for the
Pelsser FORMFEED[Page 17]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
protection of ``Primary 2'' is illustrated on figure 13.
In case no appropriate Bypass tunnel is available for the protection
of the entry ASBR and its upstream link, a new Bypass tunnel needs
to be established according to the mechanisms previously exposed.
That is, the PLR needs to create a Path message with a Bypass object
containing the downstream entry ASBR and the SRLG of the link to be
avoided by the Bypass tunnel. The Bypass tunnel is then established
in the same way as a Detour LSP protecting that same entry ASBR.
4 Security considerations
This document does not introduce new security issues. The security
considerations pertaining to the original RSVP-TE protocol [ABG^+01]
remain relevant.
5 Conclusion
In this document, we have proposed a method to establish interdomain
LSPs that fulfills the transparency requirements of the interdomain
environment while still supporting route pinning and the
establishment of secondary LSPs which can be used for load balancing
or to provide path protection in case of link or node failures. Our
solution requires the definition of a few new objects and
subobjects. An important advantage of our solution is that only AS
border LSRs need to be modified to support the proposed extensions to
RSVP-TE ; the LSRs inside an AS can still rely on the current RSVP-TE
implementation.
Then, we looked at the establishment of Detour LSPs and Bypass
tunnels for the protection of these interdomain working LSPs. More
specifically, we payed attention to the protection of interdomain
links and AS Border Routers, relying on existing solutions for the
protection of intradomain links and core routers. The elaborated
solution enables to takes into account the protection of SRLGs in
the establishment of Detour LSPs and in the use or establishment of
Bypass tunnels.
Finally, in appendix, we look at an other application of the
mechanisms developed in the first two sections of the draft. That is
the possibility to provide end-to-end protection of interdomain
links as well as being able to establish disjoint LSPs to load
balance the traffic on these LSPs.
These features require extensions to existing RSVP-TE objects by
adding new subobjects and new flags. Some objects and flags from
[PGS^+02] are used and a new object is introduced. These
modifications need only to be supported by ASBRs and the head-end
Pelsser FORMFEED[Page 18]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
LSRs who are now able to use these interdomain LSP establishment and
protection features. The objects needed for local protection through
Detour LSPs and Bypass tunnels need to be supported by all PLR on
the path of the LSP to protect. This service however requires the
support of the same objects by all PLR on the path of an intradomain
LSP.
6 Acknowledgements
This work was supported by the European Commission within the IST
ATRIUM project. We would like to thank Stefaan De Cnodder, Jean-
Philippe Vasseur and Sebastien Tandel for their useful comments.
Authors' Addresses
Cristel Pelsser
Infonet group (FUNDP)
Rue Grandgagnage 21, B-5000 Namur, Belgium
Email: cpe@info.fundp.ac.be
URL : http://www.info.fundp.ac.be/~cpe
Olivier Bonaventure
Universite catholique de Louvain (UCL)
Email: Bonaventure@info.ucl.ac.be
URL : http://www.info.ucl.ac.be/people/OBO/
Appendix
A Establishment of disjoint LSP
Another issue to consider is the establishment of a
disjoint LSP either for backup or load balancing
purposes. In this section, we show how it is possible to
establish a new LSP that is path-disjoint from an
existing LSP while still meeting the transparency
requirements concerning internal AS topologies.
Inside a single domain organized as a single IGP area, the
establishment of a path-disjoint backup LSP is simple.
The source LSR can determine the entire path of the
existing LSP thanks to the RRO object and use this
information with the topology distributed by the IGP to
select a new path that is disjoint from the existing one.
When the AS is organised in several IGP areas, the
situation is more complex since the source LSR does not
know the detailed topology of the entire network. However,
the source LSR can use the RRO object to determine the
entire path of the existing LSP and to specify a list of
Pelsser FORMFEED[Page 19]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
the IP addresses to avoid for the new LSP as constraints
in the RSVP Path message [VIZ^+02]. When considering
interdomain LSPs, this solution is not applicable since
the source LSR will only receive a summarized RRO object.
To establish a backup path that is path disjoint from a
primary path, we propose to use the new Avoid Route
Object (ARO). It is used to specify the path of the
existing LSP from which the new backup LSP should be path
disjoint. It supports the following subobjects : IPv4 and
IPv6 address prefixes as well as AS numbers. In the ARO,
an AS number subobject is always preceded by the entry
point address and followed by an exit point address.
When establishing a path disjoint backup interdomain LSP,
an LSR can rely on the RRO object stored in its path
state to determine the path of the primary LSP inside the
current AS. Based on this information, the source LSR may
compute a disjoint path. Two types of disjoint path can be
envisaged. First, the path of the LSP could be disjoint
when considering the intermediate AS. In this case, the
source LSR needs to create an ERO object that is
completely different from the ERO object of the LSP to
protect. A second type of disjoint path is a path that
passes through the same intermediate AS as the LSP to
protect but through different routers inside these AS. We
consider the latter type of disjoint paths in the
remaining of this section. Within this second type of
disjoint path, it is also possible to provide either
end-to-end or segment protection.
To establish a disjoint path with the same AS path as the
primary, the source LSR can proceed as follows. Since it
knows from the stored RRO object the IP address of the
entry point in the first downstream AS, it may easily
choose another IP address to enter the downstream AS (e.g.
based on its BGP table). The path inside the first AS
will thus automatically be disjoint from the existing
LSP. Once the Path message reaches the ASBR of the first
downstream AS, this ASBR will have to compute a path
inside this AS that will be disjoint from the path
followed by the existing LSP. This ASBR does not have
itself enough information to compute this new path.
Instead, it will ask the ASBR that is the entry point for
the primary LSP to compute a disjoint path. The address
of this ASBR can be easily obtained from the ARO object
that contains the summarised RRO of the primary LSP. The
computation of such a disjoint path requires extensions
Pelsser FORMFEED[Page 20]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
to RSVP similar to those proposed in [VIZ^+02] and a way
to specify in the path computation message the
identification of the primary LSP. Dedicated path
computation servers as in [VIZ^+02] may be envisaged for
the computation of disjoint LSPs taking this functionality
away from the ASBRs.
The primary LSP has to be identified in the Path message
of the backup LSP such that the ingress ASBR of the
primary path may identify the primary LSP and compute a
disjoint path based on the RRO stored in the path-state
of the primary LSP. In [ABG^+01], a traffic engineered
tunnel is identified by the session and the sender
template objects. More precisely, the tunnel end point
address, the tunnel ID, the extended tunnel ID and the
tunnel sender address identify a tunnel while the LSP ID
serves to reroute an established tunnel or to modify the
bandwidth reserved for the tunnel. If we consider that
establishing a backup path consists of rerouting the
primary path, the identifier of the backup LSP is the
same as the identifier of the primary path and this
identifier is carried in the Path message of the backup
LSP. No new object is required. Only the LSP ID changes.
If both paths share a common link, which should not occur
in this case, the resources will only be reserved once,
when the Shared Explicit flag of the session attribute
object is set (6). The source of the tunnel has to refresh
both paths such that they are both present in the network
(7). Figure 14 illustrates the establishment of a backup
LSP, where Avoid LSP Identifier (ALSPId) denotes the
identifier of the LSP to avoid, i.e. the identifier of
the primary LSP composed of the tunnel end point address,
the tunnel ID, the extended tunnel ID and the tunnel
sender address. In case the disjoint LSP is established
for load balancing purposes, we may not want to share
resources between the LSPs. Therefore, different tunnel
IDs are attributed to the primary and the disjoint LSP.
And, it is necessary to carry a new object, the ALSPId
object, that stores the identifier of the primary LSP, in
the disjoint LSP establishment.
Figure may be found in the postscript version [PB02] of this draft
Figure 14: Inter-domain disjoint LSP
When an AS is composed of multiple areas, an ASBR may not
be able to compute the path of an LSP through the whole
AS. Therefore, it may be necessary to store the
aggregated information concerning the primary path inside
Pelsser FORMFEED[Page 21]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
the path message of the disjoint LSP. We propose that the
ingress ASBR of a primary path communicates the RRO of
the primary path to the ingress ASBR of the backup path.
The ingress ASBR of the backup path then stores the
aggregated RRO object of the primary path into the Avoid
Route Object (ARO). The computation of the backup path
for the area is then either performed by the primary or
the backup ingress ASBR. Once the Path message reaches an
ABR, this ABR computes the path of the backup LSP for the
next area based on the ARO or based on interarea
techniques such as [VIZ^+02]. When the Path message
finally reaches the border of the AS, the information
concerning the topology of the AS must be removed from
the ARO in the same manner as aggregation of the RRO
object is performed. Based on the ARO, each router inside
an AS, in particular ingress ASBR, knows the route to
avoid inside the AS as well as the BGP NH to avoid.
Figure 15 illustrates the use of the ARO for the
establishment of a path disjoint LSP.
Figure may be found in the postscript version [PB02] of this draft
Figure 15: Role of the ARO object
B Inter-domain tunnels related message formats
Some new objects are defined for the support of
inter-domain Traffic Engineered LSPs and their
restoration. And, extensions to some objects defined in
[ABG^+01] are also introduced.
B.1 Explicit Route Object
The `EXPLICIT_ROUTE' object (ERO) has the following
format:
Class = 20, C_Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is unchanged from [ABG^+01]. The ERO may be present in Path
messages. As in [ABG^+01], only the first ERO is meaningful when a
Path message contains multiple EROs. Subsequent EROs MAY be ignored
Pelsser FORMFEED[Page 22]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
and SHOULD NOT be propagated.
B.1.1 Subobjects
The ERO is composed of a serie of variable length objects called
subobjects. Each subobject has the form:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
|L| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
where
L
The L bit is an attribute of the subobject. The L bit is set
if the subobject represents a loose hop in the explicit route.
If the bit is not set, the subobject represents a strict hop
in the explicit route.
Type
The Type indicates the type of contents of the subobject. The
values defined in [ABG^+01] are 1 (IPv4 prefix), 2 (IPv6 prefix)
and 32 (autonomous system number).
Length
The Length contains the total length of the subobject in
bytes, including the L, Type and Length fields. The Length
MUST be at least 4, and MUST be a multiple of 4.
The syntax of the IPv4 prefix is as follows:
0
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
Pelsser FORMFEED[Page 23]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
The L bit is an attribute of the subobject. The L bit is set
if the subobject represents a loose hop in the explicit route.
If the bit is not set, the subobject represents a strict hop in
the explicit route.
Type
0x01 IPv4 address
Length
The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length is always 8.
IPv4 address
An IPv4 address. This address is treated as a prefix based on
the prefix length value below. Bits beyond the prefix are
ignored on receipt and SHOULD be set to zero on transmission.
Prefix length
Length in bits of the IPv4 prefix
Flags
TBD loose destination
Indicates that the destination of the LSP may be any
router inside this abstract node.
TBD used for routing purposes
Indicates that the prefix is used for routing purposes.
The establishment of the LSP is stopped once the Path
message enters the AS to which this prefix belongs.
The contents of an IPv4 prefix subobject are a 4-octet IPv4 address,
a 1-octet prefix length, and a 1-octet flags field. The abstract
node represented by this subobject is the set of nodes that have an
IP address which lies within this prefix. Note that a prefix length
of 32 indicates a single IPv4 node.
The syntax of the IPv6 prefix is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pelsser FORMFEED[Page 24]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
|L| Type | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
The L bit is an attribute of the subobject. The L bit is set
if the subobject represents a loose hop in the explicit route.
If the bit is not set, the subobject represents a strict hop in
the explicit route.
Type
0x02 IPv6 address
Length
The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length is always 20.
IPv6 address
An IPv6 address. This address is treated as a prefix based on
the prefix length value below. Bits beyond the prefix are
ignored on receipt and SHOULD be set to zero on transmission.
Prefix Length
Length in bits of the IPv6 prefix.
Flags
TBD loose destination
Indicates that the destination of the LSP may be any
router inside this abstract node.
TBD used for routing purposes
Indicates that the prefix is used for routing purposes.
The establishment of the LSP is stopped once the Path
Pelsser FORMFEED[Page 25]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
message enters the AS to which this prefix belongs.
The contents of an IPv6 prefix subobject are a 16-octet IPv6
address, a 1-octet prefix length, and a 1-octet flags field. The
abstract node represented by this subobject is the set of nodes that
have an IP address which lies within this prefix. Note that a prefix
length of 128 indicates a single IPv6 node.
The syntax of the AS number subobject is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
|L| Type | Length | AS number (2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
L
The L bit is an attribute of the subobject. The L bit is set
if the subobject represents a loose hop in the explicit route.
If the bit is not set, the subobject represents a strict hop in
the explicit route.
Type
0x20 AS number
Length
The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length is always 4.
AS number
An AS number.
The contents of an Autonomous System (AS) number subobject are a 2-
octet AS number. The abstract node represented by this subobject is
the set of nodes belonging to the autonomous system.
Changes are required to the ERO subobjects syntax. The previous resvd
field of the IPv4 and IPv6 prefix subobjects has become a flag field.
The ``loose destination'' flag is used to indicate that the
destination of the LSP is the first router inside the prefix crossed
by the Path message. The other flag indicates that the prefix is
used for routing purposes. In that case, the destination of the LSP
Pelsser FORMFEED[Page 26]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
may be any router
inside the AS to which the prefix belongs. In case the ``used for
routing purposes'' flag is used in a prefix subobject, this subobject
MUST be preceded by an AS number subobject. This AS number subobject
is used to determine if the AS destination is reached before removing
the last subobject of the ERO. This last subobject is a prefix and
carries the ``used for routing purposes'' flag. More precisions about
the processing of the ERO due to the presence of these flags are
given in SectionB.1.2.
These changes affect the handling of the ERO at the border routers of
an AS. Additional optional changes are necessary for the support of
the ``loose destination'' flag at routers that may be the end point
of interdomain tunnels established with a prefix destination.
B.1.2 Handling of the ERO
The ``loose destination'' and ``used for routing purposes'' flags are
exclusive. If both flags are present only the ``used for routing
purposes'' flag is taken into account by a router. An IPv4 or IPv6
prefix subobject with these flags set MUST always be the last
subobject inside the ERO. A prefix subobject (IPv4 or IPv6) with flag
``used for routing purposes'' set MUST be preceded by an AS number
subobject to ensure that the AS destination is reached before
stopping the LSP's establishement.
When a router encounters an IP prefix subobject with the ``loose
destination'' flag set, during the processing of the ERO, it stops
forwarding the Path message if it belongs to the prefix. Otherwise,
the router updates the ERO with new subobjects in order to join the
prefix.
A router that has to process an AS number subobject either removes
the subobject if it belongs to the AS or adds new subobjects, that
will be used for joining the next AS, based on the Path message's
destination if necessary. Once an AS number subobject is removed,
the following subobject to process may be an IP prefix with the
``used for routing purposes'' flag set. In that case, the Path
message is terminated and a Resv message is generated since the
destination of the LSP has been reached.
B.1.3 Non-support of the ERO or of its subobjects
The Class-Num of the `EXPLICIT_ROUTE' object is of the form `0bbbbbbb
' where b represents a bit. An RSVP router that does not recognize
the `EXPLICIT_ROUTE' object sends a PathErr with the error code
"Unknown Object Class" toward the sender. This causes the path setup
to fail. The sender should notify management that an LSP cannot be
Pelsser FORMFEED[Page 27]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
established and possibly take action to continue the reservation
without the `EXPLICIT_ROUTE' or via a different explicit route.
As in [ABG^+01], a node which encounters an unrecognized subobject
during its normal ERO processing sends a PathErr with the error code
"Routing Error" and error value of "Bad Explicit Route Object"
toward the sender. The `EXPLICIT_ROUTE' object is included,
truncated (on the left) to the offending subobject. The presence of
an unrecognized subobject which is not encountered in a node's ERO
processing SHOULD be ignored. It is passed forward along with the
rest of the remaining ERO stack.
The modifications brought to the ERO subobjects are backward
compatible with [ABG^+01]. We added two flags to the IPv4 and IPv6
prefix subobjects.
A node that has to process a subobject with the ``loose destination''
flag, should stop forwarding the Path message and generate a Resv
message if it belongs to the abstract node. If it does not support
the flag and belongs to the abstract node, it will forward the Path
message to another node on the way to the destination of the Path
message. In this case, the Path message will not be ended at the
entrance of the prefix destination.
The ``used for routing purposes'' flag indicates that the prefix
subobject is only used for routing. In case this flag is not
supported, the path message will be forwarded on the path to join
the prefix. It should be ended inside this prefix depending on the
destination of the Path message (i.e. the tunnel end point address
inside the Session Object).
All nodes should forward the flags with the subobjects. They must
not set the flags field to zero on transmission. This is a
modification from [ABG^+01]. In case this is no enforced, the
setting of the flags back to zero leads to a similar situation as
described in the previous paragraphs where the flags are not
supported by the node that needs to deal with it.
B.2 Record Route Object
The `RECORD_ROUTE' object (RRO) has the same format as in [ABG^+01].
Class = 21, C_Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
Pelsser FORMFEED[Page 28]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RRO can be present in both RSVP Path and Resv messages. If a Path
message contains multiple RROs, only the first RRO is meaningful.
Subsequent RROs SHOULD be ignored and SHOULD NOT be propagated.
Similarly, if in a Resv message multiple RROs are encountered
following a `FILTER_SPEC' before another `FILTER_SPEC' is
encountered, only the first RRO is meaningful. Subsequent RROs SHOULD
be ignored and SHOULD NOT be propagated.
B.2.1 subobjects
Two additional subobjects to the RRO are required. These are the
Autonomous System (AS) number and the Shared Risk Link Group (SRLG)
number subobjects. Therefore, two new types of subobjects have to be
assigned. Furthermore, the IPv4 prefix and the IPv6 prefix
subobjects are a generalization of the IPv4 and IPv6 address
subobjects defined in [ABG^+01]. A new flag, called the ``entry
ASBR'' flag, is added inside the IPv4 and IPv6 address subobjects.
The IPv4 and IPv6 prefix subobjects are identical to the IPv4 and
IPv6 address subobjects defined in [ABG^+01] except that the prefix
length field is not set to 32 and 128, respectively. This field may
take any value in the interval 0-32 for the IPv4 prefix subobject
and between 0-128 for the IPv6 prefix subobject. These subobjects
are generalized in regards to future uses concerning the aggregation
of information obtained by means of the RRO.
The Label subobject is unchanged from [ABG^+01].
The syntax of the IPv4 address/prefix subobject is as follows:
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 | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
0x01 IPv4 address
Length
Pelsser FORMFEED[Page 29]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length is always 8.
IPv4 address
An IPv4 address. This address is treated as a prefix based on
the prefix length value below. Bits beyond the prefix are
ignored on receipt and SHOULD be set to zero on transmission.
Prefix length
Length in bits of the IPv4 prefix.
Flags
0x01 Local or segment protection available
If prefix length is 32:
Indicates that the link downstream of this node is
protected via a local repair mechanism. This flag can
only be set if the Local protection flag was set in the
SESSION_ATTRIBUTE object of the corresponding Path
message.
If prefix length < 32:
Indicates that the segment of the LSP inside the
abstract node is protected against link failures. This
flag can only be set if the segment protection flag was
set in the SESSION_ATTRIBUTE object of the
corresponding Path message.
0x02 Local or segment protection in use
If prefix length is 32:
Indicates that a local repair mechanism is in use to
maintain this tunnel (usually in the face of an outage
of the link it was previously routed over).
If prefix length < 32:
Indicates that a local or segment repair mechanism is
in use to maintain this tunnel (usually in the face of
an outage of the link it was previously routed over).
0x04 Bandwidth protection
The Point of Local Repair (PLR) will set this when the
protected LSP has a backup path which provides the
desired bandwidth, which is that in the FAST_REROUTE
Pelsser FORMFEED[Page 30]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
object or the bandwidth of the protected LSP, if no
FAST_REROUTE object was included. The PLR may set this
whenever the desired bandwidth is guaranteed; the PLR
MUST set this flag when the desired bandwidth is
guaranteed and the "bandwidth protection desired" flag
was set in the SESSION_ATTRIBUTE object.
0x08 Node protection
When set, this indicates that the PLR has a backup path
providing protection against link and node failures on
the corresponding path section. In case the PLR could only
setup a link-protection backup path, the "Local protection
available" or the "Segment protection available" bit will
be set but the "Node protection" bit will be cleared.
TBD SRLG protection
When set, this indicates that the PLR has a backup path
providing protection against SRLG failures on the
corresponding path section.
TBD Entry ASBR
Indicates that this subobject represents a router that
is the entry point inside the current AS.
The flags ``Bandwidth protection'' and ``Node protection'' are
introduced in draft [PGS^+02]. In that draft, two objects
(`FAST_REROUTE' and `DETOUR'), a few flags and the
`MAX_PROTECTED_BANDWIDTH RRO' subobject are introduced. The ``Local
protection available'' and ``Local protection in use'' flags
are extended here to ``Local or segment protection available''
and ``Local or segment protection in use'' in order to indicate
if link protection is available or in use on a path segment. This
is useful when aggregation of the RRO into IP prefixes is
performed for topology hiding purposes. The ``SRLG
protection'' flag is added to indicate if a backup path that
protects against SRLG failures is available. Moreover, the ``Entry
ASBR'' flag is introduced here to be able to perform aggregation of
the RRO at the border of an AS.
The syntax of the IPv6 address/prefix subobject is as follows:
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 | Length | IPv6 address (16 bytes) |
Pelsser FORMFEED[Page 31]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
0x02 IPv6 address
Length
The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length is always 20.
IPv6 address
An IPv6 address. This address is treated as a prefix based on
the prefix length value below. Bits beyond the prefix are
ignored on receipt and SHOULD be set to zero on transmission.
Prefix Length
Length in bits of the IPv6 prefix.
Flags
0x01 Local or segment protection available
If prefix length is 32:
Indicates that the link downstream of this node is
protected via a local repair mechanism. This flag can
only be set if the Local protection flag was set in the
SESSION_ATTRIBUTE object of the corresponding Path
message.
If prefix length < 32:
Indicates that the segment of the LSP inside the
abstract node is protected against link failures. This
flag can only be set if the segment protection flag was
set in the SESSION_ATTRIBUTE object of the
corresponding Path message.
0x02 Local or segment protection in use
Pelsser FORMFEED[Page 32]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
If prefix length is 32:
Indicates that a local repair mechanism is in use to
maintain this tunnel (usually in the face of an outage
of the link it was previously routed over).
If prefix length < 32:
Indicates that a local or segment repair mechanism is
in use to maintain this tunnel (usually in the face of
an outage of the link it was previously routed over).
0x04 Bandwidth protection
The PLR will set this when the protected LSP has a backup
path which provides the desired bandwidth, which is that in
the FAST_REROUTE object or the bandwidth of the protected
LSP,
if no FAST_REROUTE object was included. The PLR may set
this
whenever the desired bandwidth is guaranteed; the PLR MUST
set
this flag when the desired bandwidth is guaranteed and the
"bandwidth protection desired" flag was set in the
SESSION_ATTRIBUTE object.
0x08 Node protection
When set, this indicates that the PLR has a backup path
providing protection against link and node failure on
the corresponding path section. In case the PLR could only
setup a link-protection backup path, the "Local protection
available" bit will be set but the "Node protection" bit
will be cleared.
TBD SRLG protection
When set, this indicates that the PLR has a backup path
providing protection against SRLG failures on the
corresponding path section.
TBD Entry ASBR
Indicates that this subobject represents a router that
is the entry point inside the current AS.
The AS number subobject is composed of a 2-octet AS number, padding
and flags. The total length of this subobject is 8 octets, including
the type and the length fields. The type field is set to `<'TBD`>'.
Pelsser FORMFEED[Page 33]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
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 | Length | AS number (2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD AS number
Length
The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length is always 8.
AS number
A 2-octet AS number (ASN).
Padding
Zero on transmission. Ignored on receipt.
Flags
0x01 Segment protection available
Indicates that the path of the LSP inside the AS is
protected. It indicates that the LSP is protected via a
local or segment repair mechanism all the way inside the AS.
This flag can only be set if the Local protection flag was
set in the SESSION_ATTRIBUTE object of the corresponding
Path message.
0x02 Segment protection in use
Indicates that a local or segment repair mechanism is in use
to maintain this tunnel (usually in the face of an outage
of the link it was previously routed over).
0x04 Bandwidth protection
The border router sets this flag when the primary LSP is
protected by one or more backup segments, all the way inside
the AS, and they provide the desired bandwidth, which is
that
Pelsser FORMFEED[Page 34]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
in the FAST_REROUTE object or the bandwidth of the protected
LSP, if no FAST_REROUTE object was included. The border
router may set this whenever the desired bandwidth is
guaranteed; the border router MUST set this flag when the
desired bandwidth is guaranteed and the "bandwidth
protection
desired" flag was set in the SESSION_ATTRIBUTE object.
0x08 Global Node protection
When set, this indicates that the path is protected against
link and node failures on the path segment inside the AS.
In
case only link-protection backup paths could be setup, the
"Segment protection available" bit will be set but the
"Node
protection" bit will be cleared.
TBD Global SRLG protection
When set, this indicates that the path is protected against
SRLG failures on the path segment inside the AS.
The SRLG number subobject contains a 4-octet SRLG identifier
according to [PPD^+02]. And, the total length of this subobject is 8
octets, including the type, the length and the padding fields. The
type field is set to `<'TBD`>'.
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 | Length | SRLG identifier (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG identifier (continued) | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B.2.2 Handling of the RRO
The RRO is used for loop detection, route pinning and disjoint path
computation.
Route pinning is performed by using the RRO in the construction of
the ERO. In [ABG^+01], the RRO subobjects are put in sequence
inside the ERO. The loose bit of the subobjects is not set since the
RRO, in that draft, is used to record all nodes on the path. In that
case, the RRO gives a complete and strict route of the LSP.
Pelsser FORMFEED[Page 35]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
At the interdomain, since aggregation of AS topologies is necessary
outside the ASs, the RRO may contain abstract nodes such as AS
numbers and IP prefixes. Therefore, some changes are to be brought
when composing the ERO. When an AS number (or an IP prefix)
subobject is found inside the RRO, an AS subobject (an IP prefix,
respectively) with the same AS number field (IP address field,
resp.) is put inside the ERO and the loose bit of the following
subobject is set.
The setting of the loose bit in the following subobject avoids the
generation of a Path Error message when that suboject is treated
since the current node probably does not belong to the abstract node.
Indeed the aggregation of the RRO has suppressed some nodes. This
results in some holes inside the recorded route. The holes
encountered may be filled with the RRO stored locally at the node
processing the ERO.
Aggregation of the RRO is performed by means of the ``entry ASBR''
flag. This flag is set when an entry ASBR, supporting the RRO
aggregation, is stored inside the RRO. It marks the entrance inside
the AS and is used to detect the nodes to remove from the RRO at the
exit ASBR.
For IPv4 and IPv6 address subobjects, the flags are set as described
in [ABG^+01] and [PGS^+02]. When we add IPv4 and IPv6 prefixes as
well as AS number subobjects inside the RRO, the setting of the
flags occurs as follows. These subobjects are used to replace IP
addresses subobjects in order not to reveal the topology inside a
network or an AS. This is what we call RRO aggregation. When
aggregation is performed, the flags of the suppressed IP address
subobjects are used to set the flags of the aggregated prefix or AS
number subobject.
The ``Link or segment protection available'' flag is set when this
flag is set inside all the replaced subobjects. The ``Link or
segment protection in use'' flag is set when this flag is set in one
of the replaced subobjects. The same is also applicable to the
``Segment protection available'' and ``Segment protection in use''
flags of the AS number subobject.
The ``Bandwidth protection'' and the ``Node protection'' flags are
described in [PGS^+02]. It is extended here to IP prefixes and AS
number subobjects to indicate if the LSP is bandwidth or node
protected all along the path inside the network or the AS,
respectively.
To indicate that SRLG protection is provided for a downstream link or
for the path segment inside a network, the ``SRLG protection'' flag
Pelsser FORMFEED[Page 36]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
is set inside the corresponding IPv4/IPv6 address subobject or
IPv4/IPv6 prefix subobject, respectively.
Loop detection is performed by each node in the following way. Each
node looks into the received RRO for subobjects that it may add. If
such subobject is met, there is a loop. This principle has to be
refined a little for interdomain LSPs. An interior router (i.e.
router at the core of an AS) looks if it finds the address of one of
its interfaces inside the RRO. In that case there is a loop and the
establishement of the LSP is terminated. An ASBR (AS border router)
checks whether one of its addresses is present in the RRO in
addition to check whether the AS number is already present in the
RRO. In both cases, loop is detected and the establishement of the
LSP is ended. The same happens in case network aggregation is
performed. At the entrance of the network, it is checked if the
network prefix is already present inside the RRO.
An advantage of RRO aggregation is that it allows to reduce the
length of the RRO, therefore causing less errors due the creation of
packets larger than the MTU.
B.2.3 Non-support of the RRO or of its subobjects
The RRO object is to be used only when all routers along the path
support RSVP and the RRO object. The RRO object is assigned a class
value of the form 0bbbbbbb. RSVP routers that do not support the
object will therefore respond with an "Unknown Object Class" error.
When processing an RRO, unrecognized subobjects SHOULD be ignored
and passed on. When processing an RRO for loop detection, a node
SHOULD parse over any unrecognized objects. Loop detection works by
detecting subobjects which could be inserted by the node itself on
an earlier pass of the object. This ensures that the subobjects
necessary for loop detection are always understood.
A node that supports the aggregation of RRO information into entry
point, AS number and exit point MUST support the flags defined in
this draft. The same applies for a node that performs network
aggregation. Therefore, these nodes are able to deal correctly with
those flags. These flags are essentially useful for the nodes
performing aggregation and for the node that initiates the LSP tunnel
establishment. The other nodes on the path of the LSP do not need to
support them they only need to transmit them inside the Path and
Resv messages.
B.3 Avoid Route Object
The Avoid Route Object (ARO) is a new object that has the following
Pelsser FORMFEED[Page 37]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
format:
Class = <TBD>, C_Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of an `AVOID_ROUTE' object are a series of variable-
length data items called subobjects. These subobjects are the same
as thoses of the RRO. There is an exception for the label subobject
which has no use inside the ARO.
The ARO can only be present in RSVP Path messages. If a Path message
contains multiple AROs, all the AROs are meaningful. This is not the
case for the ERO and the RRO.
B.3.1 subobjects
As for the RRO, we have the IPv4 and IPv6 prefix subobjects as well
as the AS number and the SRLG number subobjects. But, for the ARO,
there is no label subobject. The IPv4 prefix, the IPv6 prefix, the
AS number
and the SRLG number subobjects have the same syntax as the
corresponding subobjects of the RRO.
In these subobjects, there are no flags defined. The flag field is
ignored on receipt and set to zero on transmission.
B.3.2 Handling of the ARO
The ARO is composed of single nodes (IP prefixes) or/and abstract
nodes. The content of this object represents the path to be avoided
by the LSP being established. The ARO is used by routers that need
to complete the ERO in order to join the next abstract node in the
ERO or the destination of the LSP. An example of the use of the ARO
object is provided in appendix A.
As well as the RRO stored in the path state at each node, the ARO may
contain holes. By holes we mean that the ARO may not contain the
whole route of the primary LSP. This results from the fact that the
ARO is formed from the RRO stored in the path state of nodes and all
nodes may not have a global view of the topology.
Pelsser FORMFEED[Page 38]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
To complete the ERO of a backup path, the ARO is used for disjoint
path computation, if it contains information about single nodes
inside the current routing domain. In case the path of the primary
LSP is not available inside the ARO, then, a node on the path of the
LSP to avoid is contacted in order to obtain that information. This
is possible since the ARO contains at least the aggregated path of
the primary LSP. Communication between a node on the backup and a
node on the primary LSP is based on the Path computation request and
reply messages defined in [VIZ^+02].
B.3.3 Non-support of the ARO or of its subobjects
Routers that must compute the route or a segment of the route of an
LSP must support the ARO if it is present in the Path message of the
LSP. Routers that can forward the Path message without looking into
the ARO, because the ERO does not need to be completed, do not need
to support the ARO. When processing the ERO, if a router needs to add
nodes into the ERO and at least an ARO is present, the router must
take the AROs into account in the computation of the path and the
ERO. In this case, if the router does not support the ARO, the
router sends an Path Err message and the LSP is not established.
Typically, ASBR and ABR need to support the ARO since these routers
are the entry point into routing domains and routing area,
respectively.
If new subobjects should be added in the future, only routers that
are completing the ERO would need to support these new subobjects. A
router that needs to compute a path based on AROs containing unknown
subobject types should send a Path Err message to the node
initiating the LSP. This message should contain the subobject types
that are unknown and the address of the node that does not support
them.
B.4 Session Attribute Object
The Session Attribute Class is 207. Two `C_Types' are defined,
`LSP_TUNNEL', `C-Type = 7' and `LSP_TUNNEL_RA', `C-Type = 1'. The
`LSP_TUNNEL_RA C-Type' includes all the same fields as the
`LSP_TUNNEL' `C-Type'. Additionally it carries resource affinity
information. The formats are as follows:
B.4.1 Format without resource affinities
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL C-Type = 7
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pelsser FORMFEED[Page 39]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Setup Priority
The priority of the session with respect to taking resources,
in the range of 0 to 7. The value 0 is the highest priority.
The Setup Priority is used in deciding whether this session can
preempt another session.
Holding Priority
The priority of the session with respect to holding resources,
in the range of 0 to 7. The value 0 is the highest priority.
Holding Priority is used in deciding whether this session can
be preempted by another session.
Flags
0x01 Local protection desired
This flag permits transit routers to use a local repair
mechanism which may result in violation of the explicit
route object. When a fault is detected on an adjacent
downstream link or node, a transit router can reroute
traffic for fast service restoration.
0x02 Label recording desired
This flag indicates that label information should be
included when doing a route record.
0x04 SE Style desired
This flag indicates that the tunnel ingress node may
choose to reroute this tunnel without tearing it down.
A tunnel egress node SHOULD use the SE Style when
responding with a Resv message.
TBD SRLG recording desired
This flag indicates that SRLG information should be
included when doing a route record.
Pelsser FORMFEED[Page 40]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
0x08 Bandwidth protection desired
This flag indicates to the PLRs along the protected LSP
path that a backup path with a bandwidth guarantee is
desired. The bandwidth which must be guaranteed is that
of the protected LSP, if no FAST_REROUTE object is
included in the PATH message; if a FAST_REROUTE object
is in the PATH message, then the bandwidth specified in
there is that which must be guaranteed.
0x10 Node protection desired
This flag indicates to the PLRs along a protected LSP
path that they must select a backup path that bypasses at
least the next node of the protected LSP.
TBD SRLG protection desired
This flag indicates to the PLRs along a protected LSP
path that they must select a backup path that bypasses
the SRLGs of the downstream link of the protected LSP.
Name Length
The length of the display string before padding, in bytes.
Session Name
A null padded string of characters.
B.4.2 Format with resource affinities
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL_RA C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
Pelsser FORMFEED[Page 41]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Exclude-any
A 32-bit vector representing a set of attribute filters
associated with a tunnel any of which renders a link
unacceptable.
Include-any
A 32-bit vector representing a set of attribute filters
associated with a tunnel any of which renders a link acceptable
(with respect to this test). A null set (all bits set to zero)
automatically passes.
Include-all
A 32-bit vector representing a set of attribute filters
associated with a tunnel all of which must be present for a
link to be acceptable (with respect to this test). A null set
(all bits set to zero) automatically passes.
Setup Priority
The priority of the session with respect to taking resources,
in the range of 0 to 7. The value 0 is the highest priority.
The Setup Priority is used in deciding whether this session can
preempt another session.
Holding Priority
The priority of the session with respect to holding resources,
in the range of 0 to 7. The value 0 is the highest priority.
Holding Priority is used in deciding whether this session can
be preempted by another session.
Flags
0x01 Local protection desired
This flag permits transit routers to use a local repair
mechanism which may result in violation of the explicit
route object. When a fault is detected on an adjacent
downstream link or node, a transit router can reroute
traffic for fast service restoration.
0x02 Label recording desired
Pelsser FORMFEED[Page 42]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
This flag indicates that label information should be
included when doing a route record.
0x04 SE Style desired
This flag indicates that the tunnel ingress node may
choose to reroute this tunnel without tearing it down.
A tunnel egress node SHOULD use the SE Style when
responding with a Resv message.
TBD SRLG recording desired
This flag indicates that SRLG information should be
included when doing a route record.
0x08 Bandwidth protection desired
This flag indicates to the PLRs along the protected LSP
path that a backup path with a bandwidth guarantee is
desired. The bandwidth which must be guaranteed is that
of the protected LSP, if no FAST_REROUTE object is
included in the PATH message; if a FAST_REROUTE object
is in the PATH message, then the bandwidth specified in
there is that which must be guaranteed.
0x10 Node protection desired
This flag indicates to the PLRs along a protected LSP
path that they must select a backup path that bypasses at
least the next node of the protected LSP.
TBD SRLG protection desired
This flag indicates to the PLRs along a protected LSP
path that they must select a backup path that bypasses
the SRLGs of the downstream link of the protected LSP.
Name Length
The length of the display string before padding, in bytes.
Session Name
A null padded string of characters.
The flags ``Bandwidth protection desired'' and ``Node protection
desired'' are defined in [PGS^+02]. The ``SRLG recording desired''
flag indicates that SRLG should be recorded inside the RRO.
Pelsser FORMFEED[Page 43]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
B.4.3 Handling of the session attribute object
This section concerns the handling of the session attribute and the
session attribute object with ressource affinities.
We take a special look at the use of the flags since two flags have
been added to these objects. We refer to [PGS^+02] for the use of
the ``Bandwidth protection desired'' and ``Node protection desired''
flags. Concerning the handling of the other fields see [ABG^+01].
The ``SRLG recording desired'' flag is used to indicate that SRLGs
should be recorded inside the RRO. These SRLGs will then be used for
the computation of disjoint SRLG paths. A node that gets a Path
message with the ``SRLG recording desired'' flag set inside the
session attribute object, should record the SRLG of the output link
on which the Path message will be forwarded after the address of the
node is recorded inside the RRO.
The ``SRLG protection desired'' flag is used to indicate that the LSP
should be protected against SRLG failures. It requires that backup
LSPs be SRLG disjoint from the segments of this LSP that they
protect. A PLR that receives a Path message with this flag set in
the session attribute object should establish a backup LSP that
avoids the SRLGs of the protected segment.
B.4.4 Non-support of the session attribute object
All RSVP routers, whether they support the `SESSION_ATTRIBUTE' object
or not, SHALL forward the object unmodified. The presence of non-
RSVP routers anywhere between senders and receivers has no impact on
this object.
A router that does not support the ``SRLG recording desired'' flag
will not store the SRLG of its output link into the RRO.
Consequently, it will not be possible to compute an SRLG disjoint
path from this LSP based only on the RRO stored in path states.
The non-support of the ``SRLG protection desired'' flag is dealt in
the same way as the non-suport of the ``Bandwidth protection
desired'' and ``Node protection desired'' flags defined in
[PGS^+02].
B.5 Session Object
There are two C-Type session objects. One is used to specify an IPv4
destination of the LSP and the other is used when the destination has
an IPv6 address. These two object types keep the same syntax as
defined in [ABG^+01]. The tunnel end point address however may be
Pelsser FORMFEED[Page 44]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
partially defined in that it may not be the effective end point of
the LSP since we have added ways to indicate inside subobject of the
ERO that the LSP may end at any router inside an AS or inside a
prefix. However, the tunnel end point address must be part of the
prefix destination or part of the AS destination.
B.5.1 LSP_TUNNEL_IPv4 Session Object
Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 tunnel end point address
IPv4 address of the egress node for the tunnel.
Tunnel ID
A 16-bit identifier used in the SESSION that remains constant
over the life of the tunnel.
Extended Tunnel ID
A 32-bit identifier used in the SESSION that remains constant
over the life of the tunnel. Normally set to all zeros.
Ingress nodes that wish to narrow the scope of a SESSION to the
ingress-egress pair may place their IPv4 address here as a
globally unique identifier.
B.5.2 LSP_TUNNEL_IPv6 Session Object
Class = SESSION, LSP_TUNNEL_IPv6 C_Type = 8
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel end point address |
Pelsser FORMFEED[Page 45]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 tunnel end point address
IPv6 address of the egress node for the tunnel.
Tunnel ID
A 16-bit identifier used in the SESSION that remains constant
over the life of the tunnel.
Extended Tunnel ID
A 16-byte identifier used in the SESSION that remains constant
over the life of the tunnel. Normally set to all zeros.
Ingress nodes that wish to narrow the scope of a SESSION to the
ingress-egress pair may place their IPv6 address here as a
globally unique identifier.
B.5.3 Handling of the session object
Each node on the path of the LSP treats the session object as usual.
But, the source of the LSP has to set the destination field in a
consistent way such that this destination may be used to join the
desired AS or network in case the end point inside either the AS or
the network does not matter.
B.5.4 Non-support of the session object
The session object should be supported by all nodes on the path of
the LSP. If it is not supported a Path Err message MUST be generated
by the node that doesn't recognize it.
Pelsser FORMFEED[Page 46]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
B.6 FAST_REROUTE Object
The FAST_REROUTE object is defined in [PGS^+02]. The FAST_REROUTE
object carries the control information, such as setup and hold
priorities and bandwidth. A protected LSP uses the FAST_REROUTE
object to specify the level of protection that is required during
local repair. The FAST_REROUTE object can be used for both one-to-one
and facility backup, and has the following format:
Class = TBD (use form 11bbbbbb for compatibility) C-Type = 1
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Setup Prio | Hold Prio | Hop-limit | Flags |
+-------------+-------------+-------------+-------------+
| Bandwidth |
+-------------+-------------+-------------+-------------+
| Include-any |
+-------------+-------------+-------------+-------------+
| Exclude-any |
+-------------+-------------+-------------+-------------+
| Include-all |
+-------------+-------------+-------------+-------------+
Setup Priority
The priority of the backup path with respect to taking resources,
in the range of 0 to 7. The value 0 is the highest priority.
Setup Priority is used in deciding whether this session can
preempt another session. See [RSVP-TE] for the usage on priority.
Holding Priority
The priority of the backup path with respect to holding
resources, in the range of 0 to 7. The value 0 is the highest
priority. Holding Priority is used in deciding whether this
session can be preempted by another session. See [RSVP-TE] for
the usage on priority.
Hop-limit
The maximum number of extra hops the backup path is allowed
to take, from current node (a PLR) to a MP, with PLR and MP
excluded in counting. For example, hop-limit of 0 means only
direct links between PLR and MP can be considered.
Pelsser FORMFEED[Page 47]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
Flags
0x01 One-to-one Backup Desired
Indicates that the LSP should be protected via the one-
to-one backup mechanism described in Section 5.
This flag can only be set by the head-end LSRs.
0x02 Facility Backup Desired
Indicates that the LSP should be protected via the facility
backup mechanism described in Section 6. This flag can
only be set by the head-end LSRs.
Bandwidth
Bandwidth estimate (32-bit IEEE floating point integer) in
bytes-per-second.
Exclude-any
A 32-bit vector representing a set of attribute filters associated
with a backup path any of which renders a link unacceptable.
Include-any
A 32-bit vector representing a set of attribute filters associated
with a backup path any of which renders a link acceptable (with
respect to this test). A null set (all bits set to zero)
automatically passes.
Include-all
A 32-bit vector representing a set of attribute filters associated
with a backup path all of which must be present for a link to be
acceptable (with respect to this test). A null set (all bits set
to zero) automatically passes.
The C-Class must be assigned in such a way that, for the LSRs that do
not support the FAST_REROUTE objects, they MUST forward the objects
downstream unchanged.
No changes are brought to the initial definition of the FAST_REROUTE
object made in [PGS^+02]. The two flags ``One-to-one Backup
Desired'' and ``Facility Backup Desired'' are very useful for the
establishment of detour LSPs or to indicate the use of bypass
Pelsser FORMFEED[Page 48]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
tunnels.
B.7 DETOUR Object
The DETOUR object is used in one-to-one backup to setup and identify
detour LSPs. It has the following format:
Class = TBD (to conform 0bbbbbbb format for compatibility) C-Type =
7
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| PLR ID 1 |
+-------------+-------------+-------------+-------------+
| Avoid Node ID 1 |
+-------------+-------------+-------------+-------------+
// .... //
+-------------+-------------+-------------+-------------+
| PLR ID n |
+-------------+-------------+-------------+-------------+
| Avoid Node ID n |
+-------------+-------------+-------------+-------------+
PLR ID (1 - n)
IPv4 address identifying the beginning point of detour which
is a PLR. Any local address on the PLR can be used.
Avoid Node ID (1 - n)
IP address identifying the immediate downstream node that
the PLR is trying to avoid. Router ID of downstream node
is preferred. This field is mandatory, and is used by
the MP for merging rules discussed below.
There could be more than one pair of (PLR_ID, Avoid_Node_ID) entry
in a DETOUR object. If detour merging is desired, after each merging
operation (Section 5.3), the MP should combine all the merged detours
in the subsequent Path messages.
The C-Class must be assigned in such a way that, for the LSRs that do
not support the DETOUR objects, the LSRs MUST reject the message and
send a PathErr to notify the PLR.
Pelsser FORMFEED[Page 49]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
In order to establish detours that are SRLG disjoint form the portion
of the working path that it protects, a new type of DETOUR object
has to be defined. This object has the following format:
Class = TBD (to conform 0bbbbbbb format for compatibility) C-Type =
TBD
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| PLR ID |
+-------------+-------------+-------------+-------------+
| Avoid Node ID |
+-------------+-------------+-------------+-------------+
| SRLG 1 |
+-------------+-------------+-------------+-------------+
// .... //
+-------------+-------------+-------------+-------------+
| SRLG n |
+-------------+-------------+-------------+-------------+
Avoid SRLG (1 - n)
SRLG of the link preceeding the node being protected.
There may be more than one SRLG for a link since a link
may belong to different Shared Risk Link Groups.
The PLR ID and the Avoid Node ID fields have the same meaning as in
the DETOUR object of C-type equals to 7.
Note that merging of detour LSPs is not possible with this object
since only one (PLR ID, Avoid Node ID) may be stored inside the
DETOUR object. This results from the possibility of storing many
SRLGs, corresponding to a single link, inside this object.
If merging of detour LSPs is desired, a DETOUR object of C-type TBD,
for each detour LSP, should be present inside the Path message of
the merged detour LSPs. Before merging these detours, it should be
checked if each detour avoids the SRLGs that have to be avoided by
each single detour.
An alternative to the use of the DETOUR object of type TBD is the
use of the ARO object defined in a previous section. The SRLGs to be
avoided are stored inside the ARO and the DETOUR object of C-type 7
is used to indicate the PLR of the detour and the node avoided by
this detour LSP.
Pelsser FORMFEED[Page 50]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
B.8 BYPASS Object
The BYPASS object is used in many-to-one protection to setup and
identify bypass tunnels. It has the following format:
Class = TBD (to conform 0bbbbbbb format for compatibility)
C-Type = 7
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| PLR ID 1 |
+-------------+-------------+-------------+-------------+
| Avoid Node ID |
+-------------+-------------+-------------+-------------+
| Avoid SRLG 1 |
+-------------+-------------+-------------+-------------+
// .... //
+-------------+-------------+-------------+-------------+
| Avoid SRLG n |
+-------------+-------------+-------------+-------------+
PLR ID
IPv4 address identifying the beginning point of detour which
is a PLR. Any local address on the PLR can be used.
Avoid Node ID
IP address identifying the immediate downstream node that
the PLR is trying to avoid. Router ID of downstream node
is preferred. This field is mandatory, and is used by
the MP for merging rules discussed below.
Avoid SRLG (1 - n)
SRLG of the link to protect or SRLG of the link preceeding the
node being protected. There may be more than one SRLG for a
link since a link may belong to different Shared Risk Link
Groups.
The C-Class must be assigned in such a way that, for the LSRs that
do not support the BYPASS objects, the LSRs MUST reject the message
and send a PathErr to notify the PLR.
Pelsser FORMFEED[Page 51]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
An alternative to storing the SRLGs to avoid inside the BYPASS object
is the use of the ARO object. These SRLGs are stored inside the ARO
and the bypass is used to indicate the node to avoid and the PLR.
References
[ABG^+01] D. Awduche, L. Berger, D.-H. Gan, T. Li, V.
Srinivasan, and G. Swallow. RSVP-TE: Extensions to RSVP
for LSP Tunnels, December 2001. RFC 3209.
[AEWX00] D. Awduche, A. Elmalid, L. Widjaja, and X.
Xiao. A framework for Internet traffic engineering,
July 2000. Work in progress,
draft-ietf-te-framework-02.txt.
[AMA^+99] D. Awduche, J. Malcom, J. Agogbua, M. O'Dell,
and J. McManus. Requirements for traffic engineering
over MPLS, September 1999. RFC 2702.
[dBPNP00] S. Van den Bosch, F. Poppe, H. De Neve, and G.
Petit. Multi-objective traffic engineering of IP
network using Label Switched Paths. In Networks 2000,
Toronto, Canada, September 2000.
[ea01] G. Bernstein et al. Optical inter domain routing
considerations. Internet draft,
draft-ietf-ipo-optical-inter-domain-00.txt, work in
progress, November 2001.
[FT00] B. Fortz and M. Thorup. Internet traffic
engineering by optimizing OSPF weights. In INFOCOM2000,
March 2000. Available at http://www.ieee-infocom.org.
[NEN02] I. Nakagawa, H. Esaki, and K. Nagami. A design
of a next generation IX using MPLS technology. In 2002
Symposium on Applications and the Internet, SAINT 2002,
Nara City, Japan, January 28 - February 1 2002.
[PB02] C. Pelsser, and O. Bonaventure. RSVP-TE
extensions for interdomain LSPs, October 2002. Work in
progress, available at
http://www.infonet.fundp.ac.be/doc/reports/.
[PGS^+02] P. Pan, D.-H. Gan, G. Swallow, J. P. Vasseur,
D. Cooper, A. Atlas, and M. Jork. Fast Reroute
Extensions to RSVP-TE for LSP Tunnels, January 2002.
Pelsser FORMFEED[Page 52]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
Work in progress,
draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt.
[PPD^+02] D. Papadimitriou, F. Poppe, S. Dharanikota, R.
Hartani, R. Jain, J. Jones, S. Venkatachalam, and Y.
Xue. Shared Risk Link Group Encoding and Processing,
June 2002. Work in progress,
draft-papadimitriou-ccamp-srlg-processing-00.txt.
[PPJ^+01] D. Papadimitriou, F. Poppe, J. Jones, S.
Venkatachalam, S. Dharanikota, R. Jain, R. Hartani, D.
Griffith, and Y. Xue. Inference of Shared Risk Link
Group, July 2001. Work in progress,
draft-many-inference-srlg-01.txt.
[SH02] V. Sharma and F. Hellstrand. Framework for
MPLS-based recovery, September 2002. Work in Progress,
draft-ietf-mpls-recovery-frmwrk-07.txt.
[VIZ^+02] J.-P. Vasseur, C. Iturralde, R. Zhang, X.
Vinet, S. Matsushima, and A. Atlas. RSVP Path
computation request and reply messages, June 2002. Work
in progress,
draft-vasseur-mpls-computation-rsvp-03.txt.
[Wan00] Z. Wang. Internet traffic engineering. Special
section of IEEE Network Magazine, March-April 2000.
[WWZ01] Y. Wang, Z. Wang, and L. Zhang. Internet traffic
engineering without full mesh overlaying. In
INFOCOM2001, April 2001. Available at
http://www.ieee-infocom.org.
----------------------------
(1) We talk about abstract nodes because it may
represent a group of physical nodes or a single node.
(2) An LSP that is node protected is protected against
any link or node failure [PGS^+02] except against the
head-end and the tail-end LSR failures.
(3) Otherwise, protecting an interdomain link would
require the establishment of a Detour LSP through at
least a third AS. We leave this case for further study
and expect that in practice AS requiring interdomain
Pelsser FORMFEED[Page 53]
draft-pelsser-rsvp-te-interdomain-lsp-00.txt October 2002
LSP protection will be multiply connected.
(4) This would be the case in figure 5 if there was a
direct link between R12 and R21 with a different SRLG
than link R13-R21.
(5) The ARO object has an additionnal use in the
establishment of end-to-end disjoint LSPs. It permits
to store the path of an LSP that has to be avoided.
(6) This should not happen if the paths are disjoint
(7) The source of the tunnel may stop refreshing the
primary path when the backup path is in use if
restoration is non revertive. The source of the tunnel
may then establish a new path as backup of the used
LSP.
Pelsser FORMFEED[Page 54]