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