1 / 55

Lecture 10

Lecture 10. 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).

kermit-slater
Télécharger la présentation

Lecture 10

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 10

  2. 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.

  3. LSP Tunnel Receiver Sender 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

  4. 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. • LABEL_REQUEST Object (carried in Path message) • LABEL Object (carried in RESV message) • Explicit Route Object (ERO) (carried in PATH and RESV messages) • RECORD_ROUTE Object (RRO) (carried in PATH/RESV messages) • SESSION_ATTRIBUTE (Carried in PATH message)

  5. Path Message Format <Path Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <POLICY_DATA> ... ] [ <sender descriptor> ] <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> [ <ADSPEC> ] RFC2205 <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> ] RFC3209

  6. Resv Message Format <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> RFC2205 <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> ] RFC3209

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

  8. LABEL_REQUEST Object Label request without label range 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label request with ATM label range 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  9. 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.

  10. 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.

  11. 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) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nodes in explicit path 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ |L| Type | Length | (Subobject contents) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ Strict/loose hop IPv4/IPv6/AS

  12. 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.

  13. 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.

  14. 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.

  15. RRO RRO 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+- Subobject 1, IPv4 Address: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+ 0x01= local protection available 0x02= local protection in use 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0x01= global label space

  16. 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.

  17. 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

  18. Path RRO (sent by R3): Path RRO (sent by R5): Path RRO (received by R6): Path RRO (sent by R1): R5 R3 R5 R1 R3 R1 R3 R1 R1 Resv RRO (received): Resv RRO (sent by R6): R5 R3 R6 R3 R6 R5 R5 R6 R6 R4 R2 R1 R6 Head Tail Path Path Path R3 R5 Resv Resv Resv Each node has a complete path information. Head-to-Self: via Path RRO Self-to-Tail: via Resv RRO

  19. 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.

  20. 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.

  21. LSP Tunnel Identification

  22. Class-Num Object Class 1 Object Class 2 Object Class n Object Type 1 Object Type 2 Object Type 7 C-Type Session Objects (e.g., SESSION) (e.g., LSP_TUNNEL_IPv4 SESSION Object) (e.g., IPv4/UDP SESSION Object) (e.g., IPv6/UDP SESSION Object) Defined in RFC2205 New C-Type

  23. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 constantover the life of the tunnel. Extended Tunnel ID A 32-bit identifier used in the SESSION that remains constantover the life of the tunnel. Normally set to all zeros.Ingress nodes that wish to narrow the scope of a SESSION to theingress-egress pair may place their IPv4 address here as aglobally unique identifier.

  24. Object Class 11 (SENDER_TEMPLATE) Class-Num Object Class 1 Object Class n (IPv4 SENDER_TEMPLATE) (IPv6 SENDER_TEMPLATE) (LSP_TUNNEL_IPv4 Sender _Template Object) Object Type 1 Object Type 2 Object Type 7 C-Type Defined in RFC2205 New C-Type LSP_TUNNEL_IPv4 Sender_Template Object

  25. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 tunnel sender address: IPv4 address for a sender node. LSP ID: A 16-bit identifier used in the SENDER_TEMPLATE and theFILTER_SPEC that can be changed to allow a sender to share resources with itself. LSP ID is changed during LSP re-optimization

  26. 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.

  27. 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 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) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  28. 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 canpreempt 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 canbe 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 whenresponding with a Resv message).

  29. 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.

  30. 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 theattributes in the set. (include-all == 0) | (((link-attr & include-all) ^ include- all) == 0)

  31. 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.

  32. 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 thistunnel 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.

  33. 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.

  34. 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.

  35. 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.

  36. 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.

  37. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RFC2328

  38. OSPF Opaque LSA Link-state ID field is interpreted differently in Opaque LSA Opaque LSAs are of LS type 9,10,11 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 | + + | ... | RFC2370 Application-specific information

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

  40. 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.

  41. 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.

  42. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LSA Header 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... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV LSA Payload More TLVs,….

  43. 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: • Link type (1 octet) • Link ID (4 octets) • Local interface IP address (4 octets) • Remote interface IP address (4 octets) • Traffic engineering metric (4 octets) • Maximum bandwidth (4 octets) • Maximum reservable bandwidth (4 octets) • Unreserved bandwidth (32 octets) • Administrative group (4 octets)

  44. 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.

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

  46. 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.

  47. Regular link-state topology database TE link-state topology database TE Topology Database R1 TE LSA

  48. 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.

More Related