CS Summer 2003 Lecture 10

CS 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 Summer 2003 LSP Tunnel Sender Receiver 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 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 Summer 2003 Path Message Format ::= [ ] [ ] [ ] [... ] ::= [ ] ::= [ ] [... ] [ ] ::= [ ] RFC2205 RFC3209

CS Summer 2003 Resv Message Format RFC2205 RFC3209 ::= [ ] [ ] [ ] [... ] ::= | ::= [ ] [ ] [ ] [... ] ::= | ::= [ ] | ::= [ ] [ ] ::= | ::= [ ]

CS 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 Summer 2003 LABEL_REQUEST Object | Reserved | L3PID | | Reserved | L3PID | |M| Res | Minimum VPI | Minimum VCI | | Res | Maximum VPI | Maximum VCI | Label request without label range Label request with ATM label range

CS 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 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 Summer 2003 ERO | | // (Subobjects) // | | // |L| Type | Length | (Subobject contents) | // Nodes in explicit path Strict/loose hopIPv4/IPv6/AS

CS 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 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 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 Summer 2003 RRO | | // (Subobjects) // | | | Type | Length | IPv4 address (4 bytes) | | IPv4 address (continued) | Prefix Length | Flags | RRO Object: Subobject 1, IPv4 Address: Subobject 3, Label: | Type | Length | Flags | C-Type | | Contents of Label Object | x01= local protection available 0x02= local protection in use 0x01= global label space

CS 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 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 Summer 2003 Head Tail R1 R2 R3 R4 R5 R6 Path 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 R6 R5 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 RRO Self-to-Tail: via Resv RRO

CS 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 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 Summer 2003 LSP Tunnel Identification

CS Summer 2003 Session Objects Class-Num Object Class 1Object Class 2Object Class n C-Type Object Type 1 Object Type 2Object 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 Summer 2003 LSP_TUNNEL_IPv4 Session Object Class = SESSION, LSP_TUNNEL_IPv4 C-Type = | 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 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.

CS 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 Summer 2003 LSP_TUNNEL_IPv4 Sender_Template Object Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 C-Type = | 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 during LSP re-optimization

CS Summer 2003

CS 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 Summer 2003 Session Attribute Object SESSION_ATTRIBUTE class = 207, LSP_TUNNEL_RA C-Type = | 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 = | Setup Prio | Holding Prio | Flags | Name Length | | | // Session Name (NULL padded display string) // | |

CS 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).

CS 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 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)

CS 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 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 Summer 2003

CS 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 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 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 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 Summer 2003 OSPF Standard LSA | LS age | Options | LS type | | Link State ID | | Advertising Router | | LS sequence number | | LS checksum | length | RFC2328

CS Summer 2003 OSPF Opaque LSA | 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 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 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 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 Summer 2003 OSPF TE LSA | LS age | Options | 10 | | 1 | Instance | | Advertising Router | | LS sequence number | | LS checksum | Length | | Type | Length | | Value... | More TLVs,…. TLV LSA Payload LSA Header

CS 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 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 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 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. Head Tail R1 R2 R3 R4 R5 R6 Link color mask may look like Link color mask may look like Tunnel 1 Tunnel 2

CS 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 Summer 2003 TE Topology Database Regular link-state topology database TE link-state topology database R1 TE LSA

CS 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 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 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 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 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 Summer 2003 TE using IGP R2 R6 R3 R4 R7R5 R1 R8 R9 R10 R3-R4-R9 path is overutlized R3-R6-R8-R9 path is underultized