1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 2 Software Processes.
CS 672 1 Summer 2003 Lecture 10. CS 672 2 Summer 2003 LSP Tunnel A traffic trunk is defined as an...
-
date post
22-Dec-2015 -
Category
Documents
-
view
214 -
download
0
Transcript of CS 672 1 Summer 2003 Lecture 10. CS 672 2 Summer 2003 LSP Tunnel A traffic trunk is defined as an...
CS 672
1
Summer 2003
Lecture 10
CS 672
2
Summer 2003
LSP Tunnel
• A traffic trunk is defined as an aggregate (or collection) of flows of same QoS. At the LSP ingress node, several flows can be mapped to the LSP (e.g., through predefined filters).
• The path of such traffic flows is determined by the path of the LSP (which normally is explicitly specified and can be different than the IGP path).
• An LSP whose path is explicitly specified is referred to as LSP Tunnel.
CS 672
3
Summer 2003
LSP Tunnel
SenderReceiver
Tunnel head Tunnel tail
The term tunnel is based on the observation that packets traversing such an LSP have been tunneled below normal IP routing
CS 672
4
Summer 2003
RSVP TE Extensions
• RSVP (RFC2205) does not have the capabilities to request and distribute label information.
• RFC3209 has defined following new objects that enable establishment of hop-by-hop or explicitly routed LSPs using RSVP.1. LABEL_REQUEST Object (carried in Path message)2. LABEL Object (carried in RESV message)3. Explicit Route Object (ERO) (carried in PATH and RESV messages)4. RECORD_ROUTE Object (RRO) (carried in PATH/RESV messages)5. SESSION_ATTRIBUTE (Carried in PATH message)
CS 672
5
Summer 2003
Path Message Format
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <EXPLICIT_ROUTE> ] <LABEL_REQUEST> [ <SESSION_ATTRIBUTE> ] [ <POLICY_DATA> ... ] <sender descriptor> <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> [ <ADSPEC> ] [ <RECORD_ROUTE> ]
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <EXPLICIT_ROUTE> ] <LABEL_REQUEST> [ <SESSION_ATTRIBUTE> ] [ <POLICY_DATA> ... ] <sender descriptor> <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> [ <ADSPEC> ] [ <RECORD_ROUTE> ]
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <POLICY_DATA> ... ] [ <sender descriptor> ] <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> [ <ADSPEC> ]
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <POLICY_DATA> ... ] [ <sender descriptor> ] <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> [ <ADSPEC> ] RFC2205
RFC3209
CS 672
6
Summer 2003
Resv Message Format
RFC2205
RFC3209
<Resv Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <RESV_CONFIRM> ] [ <SCOPE> ] [ <POLICY_DATA> ... ] <STYLE> <flow descriptor list> <flow descriptor list> ::= <empty> | <flow descriptor list> <flow descriptor>
<Resv Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <RESV_CONFIRM> ] [ <SCOPE> ] [ <POLICY_DATA> ... ] <STYLE> <flow descriptor list> <flow descriptor list> ::= <empty> | <flow descriptor list> <flow descriptor>
<Resv Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <RESV_CONFIRM> ] [ <SCOPE> ] [ <POLICY_DATA> ... ] <STYLE> <flow descriptor list> <flow descriptor list> ::= <FF flow descriptor list> | <SE flow descriptor> <FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ] | <FF flow descriptor list> <FF flow descriptor> <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ] <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list> <SE filter spec list> ::= <SE filter spec> | <SE filter spec list> <SE filter spec> <SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
<Resv Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <RESV_CONFIRM> ] [ <SCOPE> ] [ <POLICY_DATA> ... ] <STYLE> <flow descriptor list> <flow descriptor list> ::= <FF flow descriptor list> | <SE flow descriptor> <FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ] | <FF flow descriptor list> <FF flow descriptor> <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ] <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list> <SE filter spec list> ::= <SE filter spec> | <SE filter spec list> <SE filter spec> <SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
CS 672
7
Summer 2003
LABEL_REQUEST Object
• LABEL_REQUEST Object is used for requesting label for a LSP tunnel.• LABEL_REQUEST Object is included in the PATH message• LABEL_REQUEST Object has three different forms corresponding to a
frame-based MPLS interface, LC-ATM and LC-FR interface.• Label request without label range• Label request with ATM label range• Label request with Frame Relay label range
CS 672
8
Summer 2003
LABEL_REQUEST Object
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | L3PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | L3PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | L3PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Res | Minimum VPI | Minimum VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res | Maximum VPI | Maximum VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | L3PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Res | Minimum VPI | Minimum VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res | Maximum VPI | Maximum VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label request withoutlabel range
Label request withATM label range
CS 672
9
Summer 2003
LABEL Object
• A new RSVP object is defined to distribute label information.• The Label Object is carried in Resv message and must follow the
FilterSpec Object for the associated sender.• RSVP-TE uses downstream-on-demand (DoD) label distribution mode.• Upon request from the upstream node, the downstream node assigns a
label.• Label is assigned from the range in the label request, if specified.
• The upstream node uses this label as the outgoing label for the LSP.
CS 672
10
Summer 2003
Explicit Route Object (ERO)
• To establish a LSP tunnel along an explicit path, RSVP TE uses the ERO.• Using ERO, path taken by an LSP tunnel can be predetermined and independent of
conventional routing.• An ERO specifies a sequence of nodes along the explicit path that must be traversed.• When ERO is present, PATH message is forwarded based on ERO towards its destination.
Each node along the path stores ERO in PSB.• If the ERO is modified (e.g., expanded), in addition to the received ERO the modified is also
stored in the PSB.
CS 672
11
Summer 2003
ERO
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) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ |L| Type | Length | (Subobject contents) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ |L| Type | Length | (Subobject contents) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
Nodes in explicit path
Strict/loose hop IPv4/IPv6/AS
CS 672
12
Summer 2003
Strict and Loose ERO
• An ERO specifies a sequence of nodes along the explicit path. The specification of nodes can be either strict or loose.
• Strict ERO – specifies all the nodes (or hops) along the explicit path that must be traversed.
• Loose ERO – specifies few nodes (or hops) along the explicit path that must be traversed.
CS 672
13
Summer 2003
ERO Expansion
• When a router receives a PATH message containing an ERO, and the next hop subobject specified as a loose hop, this router expands the subobject.
• As a result of subobject expansion, the router replaces the loose subobject with one or more strict subobjects.
• The router performing the loose ERO expansion, must have the information (e.g., topology data base) to determine the best route to the loose hop.
CS 672
14
Summer 2003
Record Route Object (RRO)
• The RRO is used for recording route information.• For example, by including RRO to the Path message, the sender node can
receive information about the actual path that an LSP traverses.• RRO is similar to Path Vector and can also be used for loop detection• The sender node can also use RRO to request notification from network
concerning changes in the routing path.
CS 672
15
Summer 2003
RRO
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) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-
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) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+
RRO Object:
Subobject 1, IPv4 Address:
Subobject 3, Label:
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 | Flags | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Contents of Label Object | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Flags | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Contents of Label Object | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x01= local protection available0x02= local protection in use
0x01= global label space
CS 672
16
Summer 2003
RRO
• The sender node includes RRO in the Path message. At this stage, RRO contains one subobject recording sender’s IP address.
• To obtain information about labels that are being used by nodes along the tunnel, the sender node request it by setting a flag in the SESSION_ATTRIBUTE Object.
• As the Path message traverse along the LSP path, each node stores a copy of the RRO in its PSB.
• When sending (initial) Path message downstream, the records its IP address and attaches a new RRO subobject.
CS 672
17
Summer 2003
RRO
• When the Path message with RRO arrives at the tunnel tail end, adds the RRO to the Resv message and forward it upstream.
• The RRO in the Resv message records the reverse path of the LSP.• If the Label_Recording flag is set in the SESSION_ATTRIBUTE Object,
the node must also record label subobject.• As the Resv message travels along the LSP path (in reverse direction),
each node stores a copy of the RRO in RSB.• When sending (initial) Resv message upstream, the records its IP address
and attaches a new RRO subobject
CS 672
18
Summer 2003
Head Tail
R1
R2
R3
R4
R5
R6
Path
Path Path
Resv
Resv
Resv
Path RRO (sent by R3):
R3
R1
Path RRO (sent by R5):
R5
R3
R1
Path RRO (sent by R1):
R1
Path RRO (received by R6):
R5
R3
R1
R6R5
R6
R3
R5
R6
R3
R5
R6
Resv RRO (received): Resv RRO (sent by R6):
Each node has a complete path information.Head-to-Self: via Path RROSelf-to-Tail: via Resv RRO
CS 672
19
Summer 2003
Forwarding Loop Detection
• RRO contains path information and can be used to detect forwarding.• When a RSVP node receives an Path/Resv RRO, it processes the
received RRO. If the node find itself listed in the RRO, this means a forwarding loop exists.
• If the loop is detected while processing the Path RRO, the node sends a PathErr message (Error=“loop detected”) upstream towards the sender.
• If the loop is detected while processing the Resv RRO, the Resv message is dropped.
CS 672
20
Summer 2003
Forwarding Loop Detection
• RRO contains path information and can be used to detect forwarding.• When a RSVP node receives an Path/Resv RRO, it processes the
received RRO. If the node find itself listed in the RRO, this means a forwarding loop exists.
• If the loop is detected while processing the Path RRO, the node sends a PathErr message (Error=“loop detected”) upstream towards the sender.
• If the loop is detected while processing the Resv RRO, the Resv message is dropped.
CS 672
21
Summer 2003
LSP Tunnel Identification
CS 672
22
Summer 2003
Session Objects
Class-Num
Object Class 1 Object Class 2 Object Class n
C-Type
Object Type 1 Object Type 2 Object Type 7
(e.g., SESSION)
(e.g., IPv4/UDP SESSION Object) (e.g., IPv6/UDP SESSION Object) (e.g., LSP_TUNNEL_IPv4 SESSION Object)
New C-Type
Defined in RFC2205
CS 672
23
Summer 2003
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RFC3209
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 IDA 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.
CS 672
24
Summer 2003
LSP_TUNNEL_IPv4 Sender_Template Object
Class-Num
Object Class 1 Object Class 11 (SENDER_TEMPLATE)
(IPv4 SENDER_TEMPLATE) (IPv6 SENDER_TEMPLATE)
C-Type
Object Type 1 Object Type 2 Object Type 7
(LSP_TUNNEL_IPv4 Sender _Template Object)
New C-Type
Defined in RFC2205
Object Class n
CS 672
25
Summer 2003
LSP_TUNNEL_IPv4 Sender_Template Object
Class = SENDER_TEMPLATE, 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 sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class = SENDER_TEMPLATE, 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 sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 tunnel sender address:IPv4 address for a sender node.
LSP ID:A 16-bit identifier used in the SENDER_TEMPLATE and the FILTER_SPEC that can be changed to allow a sender to share resources with itself.
LSP ID is changed duringLSP re-optimization
CS 672
26
Summer 2003
CS 672
27
Summer 2003
SESSION ATTRIBUTE Object
• RFC3209 defines a new object class (Class-Num = 207) known as SESSION_ATTRIBUTE class. It contains two objects:• LSP_TUNNEL_RA (C-Type = 1)• LS_TUNNEL (C-Type = 7)
• LSP_TUNNEL_RA object is used when tunnel setup must consider resource affinities.
CS 672
28
Summer 2003
Session Attribute Object
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) // | | +-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) // | | +-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Prio | Holding Prio | Flags | Name Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Session Name (NULL padded display string) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Prio | Holding Prio | Flags | Name Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Session Name (NULL padded display string) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CS 672
29
Summer 2003
Session Attribute Object
Exclude-any, Include-any, Include-all:Filters associated with a tunnel which are to link attributes for excluding or including a link for path selection.
Setup Priority:The priority of the session with respect to taking resources, in the range of 0 (highest) to 7. 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 (highest) to 7. Holding Priority is used in deciding whether this session can be preempted by another session.
Flags: 0x01 Local protection desired (to request local repair via FRR) 0x02 Label recording desired (in RRO) 0x04 SE Style desired (e.g., for LSP re-optimization). (A tunnel egress node SHOULD use the SE Style when responding with a Resv message).
Exclude-any, Include-any, Include-all:Filters associated with a tunnel which are to link attributes for excluding or including a link for path selection.
Setup Priority:The priority of the session with respect to taking resources, in the range of 0 (highest) to 7. 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 (highest) to 7. Holding Priority is used in deciding whether this session can be preempted by another session.
Flags: 0x01 Local protection desired (to request local repair via FRR) 0x02 Label recording desired (in RRO) 0x04 SE Style desired (e.g., for LSP re-optimization). (A tunnel egress node SHOULD use the SE Style when responding with a Resv message).
CS 672
30
Summer 2003
Resource Class Affinities
• Resource class attributes are administratively assigned link state parameters (32-bit mask) flooded through IGP opaque LSAs.
• Each bit in the mask correspond to a link resource class or color.• If we wish to tunnel to avoid links with certain resource color, this
information is specified in the resource affinities fields in the SESSION Attribute.
• By comparing tunnel SESSION and the link resource class attributes (colors), we can apply some policies (or constraints) for placement of tunnels on specific types of links.
CS 672
31
Summer 2003
Resource Affinities Comparisons
1. Exclude-any This test excludes a link from consideration if the link carries any of the attributes in the set.
(link-attr & exclude-any) == 0 2. Include-any This test accepts a link if the link carries any of the attributes in the set. (include-any == 0) | ((link-attr & include-any) != 0) 3. Include-all This test accepts a link only if the link carries all of the attributes in the set. (include-all == 0) | (((link-attr & include-all) ^ include- all) == 0)
1. Exclude-any This test excludes a link from consideration if the link carries any of the attributes in the set.
(link-attr & exclude-any) == 0 2. Include-any This test accepts a link if the link carries any of the attributes in the set. (include-any == 0) | ((link-attr & include-any) != 0) 3. Include-all This test accepts a link only if the link carries all of the attributes in the set. (include-all == 0) | (((link-attr & include-all) ^ include- all) == 0)
CS 672
32
Summer 2003
Preemption Priorities
• Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network.
• Without preemption priority, flows are admitted on a first-come-first-serve basis.
• With preemption priority, the impact order of flows arrival is minimized, because network nodes may preempt previously admitted low priority flows to allow new higher priority flows.
CS 672
33
Summer 2003
Preemption Priorities
• In RSVP-TE, preemption is specified in terms of two priorities:• Setup Priority – is the priority for taking (i.e., setting aside but not reserving) resources
while the tunnel is being established.• Holding Priority – is the priority at which resources assigned to this tunnel will be
reserved (after tunnel has been established). Once a tunnel has been established, its holding priority is compared with the setup priority of new tunnels.
• For instance, a medium setup priority makes it harder for a tunnel to preempt others (in progress and established tunnels), however, once established, a higher holding priority makes it easier for the tunnel to avoid being preempted itself.
CS 672
34
Summer 2003
CS 672
35
Summer 2003
Constraint-based Routing
• Constraint-based routing refers to routing algorithms that compute their paths satisfying a set of constraints such as bandwidth, delay, hop counts, resource class, etc.
• Constrained-based paths are not necessarily the shortest paths.• Constraint-based routing is well-suited for path oriented transport
technologies (e.g., ATM, MPLS) that support explicit routing.• Because paths can be explicitly specified, constraint-based routing
can be used to redistribute traffic in the network.
CS 672
36
Summer 2003
Constraint-based IGP
• In the conventional link-state IGPs (i.e., OSPF, IS-IS), path computation is based on Shortest Path First (SPF) algorithm.
• In order to support constraint-based routing, SPF algorithm also needs to consider constraints during path computation process. The enhanced SPF algorithm is referred to as constrained SPF (CSPF).
• For CSPF to function, the constraints related information must be available in each router.
CS 672
37
Summer 2003
IGP Extensions
• A number of enhancements are required in IGP to propagate this additional link-state information.
• In summary, these extensions require propagation of additional information such as available bandwidth and link resource class.
• In OSPF, the additional link-state information is propagated through Opaque LSAs.
CS 672
38
Summer 2003
OSPF Opaque LSAs
• Opaque LSAs provide a method for extending OSPF capabilities.• Opaque LSAs are similar to standard OSPF LSAs in following aspects:
• Contain a standard LSA header• Use the normal link-state distribution procedures for flooding this information through the area
• Opaque LSAs are link-state advertisements of types 9, 10, and 11• Opaque LSAs contain an application-specific fields after the standard LSA header.
CS 672
39
Summer 2003
OSPF Standard LSA
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RFC2328
CS 672
40
Summer 2003
OSPF Opaque LSA
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 9, 10 or 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Opaque Information | + + | ... |
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 9, 10 or 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Opaque Information | + + | ... |
Link-state ID field is interpreted differently in Opaque LSA
Application-specific information
Opaque LSAs are of LS type 9,10,11
RFC2370
CS 672
41
Summer 2003
Flooding Scope
• Opaque LSAs of LS type = 9 have a link-local flooding scope (i.e., not flooded beyond the attached subnet)
• Opaque LSAs of LS type = 10 have an area-local flooding scope (i.e., not flooding beyond the area that they are originated).
• Opaque LSAs of type = 11 has an AS-wide flooding scope (i.e., flooded throughout the AS with the exception of stub-areas)
CS 672
42
Summer 2003
OSPF TE Extensions
• OSPF TE extensions define topology information such as:• Link bandwidth • Link resource affinities etc….
• Using Opaque LSAs, the above information is distributed through an area.• Through a collection of such LSAs, a router can build a TE topology database.• The TE topology database allows computation of CSPF paths to place TE
tunnels.
CS 672
43
Summer 2003
TE Topology Database
• The OSPF TE extension use Opaque LSA of type 10 (i.e., area-local flooding scope).• Thus OSPF TE extensions are used for intra-area TE applications (inter-area and inter-AS TE applications
is beyond the scope of this course).• Using Opaque LSAs, the above information is distributed through an area.• A collection of such LSAs defines what is commonly referred to as extended link-state
database or TE topology database.• In contrast with “regular” topology database, TE topology database contains more
information about link attributes (e.g., bandwidth) which is needed for computing CSPF paths.
CS 672
44
Summer 2003
OSPF TE LSA
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
More TLVs,….
TLV
LSA Payload
LSA Header
CS 672
45
Summer 2003
OSPF TE TLVs
• OSPF TE LSA payload contains Router Address (i.e., router IP address) and Link (i.e., link attributes) TLVs. • Link contains following sub-TLVs:
1. Link type (1 octet)2. Link ID (4 octets)3. Local interface IP address (4 octets)4. Remote interface IP address (4 octets)5. Traffic engineering metric (4 octets)6. Maximum bandwidth (4 octets)7. Maximum reservable bandwidth (4 octets)8. Unreserved bandwidth (32 octets)9. Administrative group (4 octets)
CS 672
46
Summer 2003
Link Sub-TLVs
• Maximum bandwidth (4 octets)• i.e., maximum link capacity (bytes/sec)
• Maximum reservable bandwidth (4 octets)• The bandwidth to be used by CAC function. Can be < or > maximum bandwidth
• Unreserved bandwidth (32 octets)• Unreserved bandwidth = reservable BW – Reserved BW
• Administrative group (4 octets) • Link resource affinities (or color). Each bit in the 32-bit mask represent a color. • These bits are assigned by by the network administrator.• Each link can be assigned multiple colors.
CS 672
47
Summer 2003
Link Colors
• Tunnel1 (head=R1, tail = R6) is created using resource affinity filter “include red”» LSP tunnel 1 is established along R1-R3-R5-R6.
• Tunnel 2 (head = R1, tail = R6) is created using resource affinity filter “include green”.» LSP tunnel 2 could be placed along R1-R2-R4-R6 or R1-R2-R3-R5-R6.
• Tunnel1 (head=R1, tail = R6) is created using resource affinity filter “include red”» LSP tunnel 1 is established along R1-R3-R5-R6.
• Tunnel 2 (head = R1, tail = R6) is created using resource affinity filter “include green”.» LSP tunnel 2 could be placed along R1-R2-R4-R6 or R1-R2-R3-R5-R6.
Head Tail
R1
R2
R3
R4
R5
R6
Link color mask may look like 00000000000000000000000000000011
Link color mask may look like 00000000000000000000000000000101
Tunnel 1
Tunnel 2
CS 672
48
Summer 2003
Originating OSPF TE LSA
• TE LSAs are originated when the contents of the LSA change (e.g., link bandwidth, color, etc.).
• Like any other LAS, TE LSAs are also originated as a part of periodic LSA refresh procedures.
• To avoid generation of excessive control traffic, some thresholds may be used to trigger these thresholds (e.g., unreserved BW falls below certain level, etc.).
• As TE LSAs are flooded through an area, upon receiving these LSAs, the routers update their TE topology database.
CS 672
49
Summer 2003
TE Topology Database
Regular link-state topology database
TE link-state topology database
R1
TE LSA
CS 672
50
Summer 2003
Traffic Engineering (TE)
• TE is the capability to direct traffic along a particular path in the network. • The key objectives of TE include:
• reduction of network operational costs by efficient utilization of network resources (e.g., bandwidth)
• efficient placement of traffic routes not to cause under utilization in a part of network while over utilization in other.
CS 672
51
Summer 2003
Traffic Engineering (TE)
• TE requires capability to:• compute (manually or automatically using IGP) paths in the network.• select paths paths meeting certain constraints (e.g., available bandwidth).• direct traffic along selected paths.
• There are three common approaches to TE:• IGP metrics optimization• ATM/FR Virtual Circuits (VCs)• MPLS TE Tunnels
CS 672
52
Summer 2003
TE via IGP Link Metric Optimization
• IGP path computation is based on SPF algorithm. • When multiple paths exist, SPF selects a path that minimizes certain additive scalar link metric.• As IGP path selection does not consider other attributes such as available bandwidth, IGP-
based forwarding may lead to following undesirable effects:• SPF paths of multiple traffic flows converge on a link(s). • Thus if the total traffic from multiple flows exceeds the link capacity of a link on the SPF path , it become
congested (while a longer path remain underutilized).• As a result, certain paths in the network are overutilized while other are underutilized.
CS 672
53
Summer 2003
TE via IGP Link Metric Optimization
• Won’t the Equal Cost Multi-Path (ECMP) SPF solve this problem?• If there are more than one SPF paths to a destination, regular SPF just picks one. • In contrast, if there are more than one equal cost paths to a destination, ECMP-SPF selects more than one path and
load-balances traffic on these paths. Two types of load-balancing is possible:• Packet-by-packet (will cause packet re-ordering)• Per-flow (i.e., per source/destination)
CS 672
54
Summer 2003
TE via IGP Link Metric Optimization
• As ECMP-SPF is also based on (static) link metrics and does not consider (dynamic) constraints such as link bandwidth, it attempts to distribute distribute traffic as evenly as possible over multiple equal costs path without considering congestion on the path. • Thus if there are two equal cost paths, ECMP can cause more congestion than the other.• Another Drawback – ECMP does not support load-balancing on multiple unequal cost paths.
• In summary, IGP metric optimization does not provide the degree of control necessary to steer traffic along a specific path.
CS 672
55
Summer 2003
TE using IGP
R2
R6
R3
R4
R7R5
R1
R8
R9
R10
R3-R4-R9 pathis overutlized
R3-R6-R8-R9 pathis underultized