RSVP and LDP: From JUNOS

Resource Reservation Protocol (RSVP):

  • IP protocol number: 46 (0x2e in Hex). Each RSVP packet has common RSVP header which consist of following fields:
    • Version – 4 bits – set to 0x01
    • Flags – 4 bits –000A. When bit A is set to 1, local router supports RSVP message aggregation.
    • Message Type – 1 octet – Used to identify each message type.
      • 1- path
      • 2-Resv
      • 3-PathErr
      • 4-ResvErr
      • 5-PathTear
      • 6-ResvTear
      • 7-ResvConf
      • 12-Bundle
      • 20- Hello
    • RSVP checksum – 2 octets – set to standard IP checksum
    • Send TTL – 1 octet – Contains identical value as IP TTL. Used to detect non-RSVP capable router along the path of an LSP.
    • Reserved – 1 octet – set to 0x00
    • RSVP length – 2 octets – entire RSVP packet length
    • Objects – each object has fixed header and variable length data field.
  • Ingress router from where LSP is created is upstream router and the egress router where the LSP terminates is downstream router. So, data flows from upstream to downstream router.
  • Path Message:
    • When a router setup LSP, it generates Path msg and forwards it downstream to egress LSR.
    • Destination IP is the IP address of the egress router. But each device examines this message as the IP router-alert option in set in IP header.
    • Outgoing interface IP address is added to RecRoute (RRO) and hop object.
    • Some set of information is stored in “path state Block”

<From traceoptions>

RSVP send Path 2.2.2.2->1.1.1.1 Len=224 em0.0

Session7 Len 16 1.1.1.1(port/tunnel ID 37445 Ext-ID 2.2.2.2) Proto 0

Hop      Len 12 10.1.2.2/0x08a0c000

Time     Len  8 30000 ms

SrcRoute Len 12  100.100.100.100 S

LabelRequest Len  8 EtherType 0x800

Properties Len 12 Primary path

SessionAttribute Len 16 Prio (7,0) flag 0x0 “to-R1”

FastReroute Len 24 Prio(7,0) Hop 6 Flag 0x1 BW 0bps Include 0x00000000 Exclude 0x00000000 IncludeAll 0x00000000

Sender7  Len 12 2.2.2.2(port/lsp ID  6)

Tspec    Len 36 rate 0bps size 0bps peak Infbps m 20 M 1500

ADspec   Len 48 MTU 1500

RecRoute Len 12  10.1.2.2

  • Resv Message:
    • Sent from egress router to its immediate upstream. Destination IP set to the interface address of upstream router. IP information is retrieved from “Hop” object in path msg.
    • “Resv state block” is created.
    • Local label is advertised to upstream router.
    • Outgoing interface IP is added to RecRoute (RRO) and hop object.

<From traceoptions>

RSVP send Resv 10.1.2.2->10.1.2.1 Len=108 em0.0

Session7 Len 16 2.2.2.2(port/tunnel ID 10 Ext-ID 1.1.1.1) Proto 0

Hop      Len 12 10.1.2.2/0x0a00040d

Time     Len  8 30000 ms

Style    Len  8 SE

Flow     Len 36 rate 0bps size 8kbps peak 0bps m 1 M 1500

Filter7  Len 12 1.1.1.1(port/lsp ID  11)

Label    Len  8  3

  • PathErr Message:
    • This does not destroy any soft state. These messages are sent in hop-hop fashion upstream.
    • Error message can be view using “show mpls lsp extensive” command.
    • Eg: Suppose if a next-hop in the strict ERO is not reachable, ingress router receive this msg.
  • ResvErr Message:
    • This does not destroy any soft state. These msg are sent in hop-hop fashion downstream.
    • Eg: When a router receives a Resv message which has ‘hop’ field address different than available in database, it generates ResvErr and send it to its downstream router.
  • PathTear Message:
    • To remove both soft and resv state information from routers.
    • Addressed to egress router but IP Alert-bit is set as in Path message.
    • Eg: If a link between 2 transit routers fails, one router generates ‘PathTear’ and send it to egress router  and another router generates ‘ResvTear’ and send it to ingress router.
  • ResvTear Message:
    • Travels upstream to ingress router in hop-hop fashion.
    • Message addressed to the interface address of previous hop router (upstream).

RSVP Objects:

  • Session Object:
    • “Session7 Len 16 1.1.1.1(port/tunnel ID 37445 Ext-ID 2.2.2.2) Proto 0”
    • This object will be available in every RSVP messages and it uniquely identifies LSP and its soft state information. In the above message:
    • “session7” implies it is session object, C-type value of 7.
    • “Len 16” implies object length of 16 bytes
    • “1.1.1.1” implies the tunnel end-point address (egress router)
    • “port/tunnel ID 37445” implies the unique number allocated to the tunnel by ingress router.
    • “2.2.2.2” denotes the ingress router ID
  • Hop object:
    • Hop      Len 12 10.1.2.2/0x08a0c000”
    • This object available in all messages is used to identify the IP interface address of neighboring RSVP router.
    • Above trace log implies the received message is sent by router via interface whose ip address is “10.1.2.2” and its local unique 32-bit ID called “logical interface handler”.
  • Time object:
    • Time     Len  8 30000 ms
    • This object available in all messages is used to advertise the local router to regenerate Path/Resv message to keep the soft state active.
    • Above trace log implies the advertising router uses 30 seconds as ‘refresh timer’
  • IPv4 Error-Spec object:
    • This object available in PathErr/ResvErr message is used to report the error seen by a router.
  • Style object:
    • Style    Len  8 FF
    • This object available in ‘Resv’ message determines how the reservations are made in the network. There are three types of reservation style.
    • Fixed Filter (FF) – Unique reservation for each RSVP session and sender object
    • Shared Explicit (SE) – multiple-sender objects that share the same session object are allowed to use same resources.
    • Wildcard Filter (WF) – set of resources shared among all resources. Not supported by JUNOS
    • JUNOS uses default – FF style
  • Integrated services flow spec object:
    • Flow     Len 36 rate 0bps size 8kbps peak 0bps m 1 M 1500
    • This object available in ‘Resv’ message determines bandwidth request of the LSP.
    • “rate 0bps size 8kbps peak 0bps” implies the BW reservation request, peak data rate.
    • “m 1 M 1500” implies the minimum and maximum packet size supported on LSP.
  • Filter-Spec object:
    • Filter7  Len 12 1.1.1.1(port/lsp ID  11)
    • This object available in ‘Resv’ message is used to uniquely identify the sender for the LSP.
    • Used in “shared explicit” share where we need to share resource from multiple sender.
    • “1.1.1.1(port/lsp ID  11)” implies the ingress router ID as 1.1.1.1 and a unique LSP ID generated by ingress router.
  • Sender-template object:
    • Sender7  Len 12 2.2.2.2(port/lsp ID  6)
    • This object available in ‘Path’ message is used to uniquely identify the sender for the LSP.
    • Same as filter object
  • Sender-Tspec object:
    • Tspec    Len 36 rate 0bps size 0bps peak Infbps m 20 M 1500
    • This object available in ‘Path’ message is used for bandwidth reservation request.
    • Same as in flow object
  • Label object:
    • “Label    Len  8  3”
    • This object available in ‘Resv’ message is used to distribute label in response to “Label request” in ‘Path’ message.
    • In this case, downstream router is requesting its upstream to perform PHP (label:3)
  • Label request object:
    • LabelRequest Len  8 EtherType 0x800
    • This object available in ‘path’ message to request its downstream routers to send label in Resv message.
    • “EtherType 0x800” to represent label for IPv4 protocol.
  • Explicit Route object:
    • “SrcRoute Len 12  100.100.100.100 S”
    • This object available in ‘path’ message allows ingress router to specify the path to be taken by LSP. It has “L bit” which when set implies ERO is loosely defined and when reset implies strict.
    • After the next-hop checks for ERO and verified its own IP, it creates a soft state, removes its IP from ERO and forwards to its downstream router.
    • “100.100.100.100 S” implies next-hop should be 100.100.100.100 strict.
  • Record Route object:
    • “RecRoute Len 12  10.1.2.2”
    • This object available in both Resv/path message is used to detect loop. When a router receives RSVP message with its own IP address in RRO, those packets are rejected.
    • While sending out RSVP message, the egress interface IP is added to the RRO object.
  • Detour object:
    • This object available in path message is used to establish a fast reroute detour in network.
    • It has ‘Local repair Node ID’ which encodes the address of the router creating the detour path. Outgoing interface ID is used in this field.
    • ‘Avoid Node ID’ is the router ID of the downstream node that is being protected.
  • Fast Reroute object:
    • FastReroute Len 24 Prio(7,0) Hop 6 Flag 0x1 BW 0bps Include 0x00000000 Exclude 0x0 IncludeAll 0x0
    • This object available in path message is used to alert all downstream routers that ingress router desires protection along the LSP path.
    • Information within this object allows each of the routers to consult TED for detour path.
    • “Prio(7,0)” implies setup priority of 7 (weakest priority) and hold priority of 0 (strongest priority). JUNOS default.
    • “Hop 6” Total number of transit hops a detour path take.  Excluding local repair node and merge node.
    • “BW 0bps”. Bandwidth reservation that should be performed for all detour paths. Default set to 0. Can be set by ‘fast-reroute’ command in LSP.
    • “Include 0x0” field: when a group value is assigned, link along the detour path must be assigned to that administrative group. Vice versa for exclude field.
  • Session attribute object:
    • SessionAttribute Len 16 Prio (7,0) flag 0x0 “to-R1”
    • This object available in path message is used advertise priority values of the LSP and name of the session.
    • “Prio (7,0)” implies the default setup and hold priority values.
    • “flag 0x0” implies flags like link/node protection, SE style, BW reservation for detour paths.
    • “to-R1” implies the name of the session.
  • In a path msg: Session, session attribute and sender-Template object uniquely defines a session.
  • In a Resv msg: Session, Filter-Spec objects uniquely identifies a session.

Label Distribution protocol:

  • No traffic engineering capabilities like in RSVP and the LSP follows the IGP shortest path.
  • Becoming LDP Neighbors:
    • When LDP protocol is enabled, each router starts sending LDP hello message destined to 224.0.0.2/32 address and SRC and DES UDP port 646. Hello message and all other messages are in TLV format.
  • Common LDP packet format:
    • LDP packet has following fields in common. LDP version – 2 octets – set to 0x01
    • PDU length – 2 octets – total LDP PDU length
    • LSP ID – 6 octets – [LSP ID value (4 octets) : label allocation method (2 octets)]
      • JUNOS set a value of 0x00 to denote per-router label allocation.
    • Message Type – 2 octets:
      • First bit also called as ‘U’ bit (Unknown) is designed as a method for telling routers how to handle a message which is unknown to local router.
      • If this bit is set to 0, router should send error message to sender
      • If this bit is set to 1, router may ignore the unknown TLV silently.
      • Remaining bits are set to a value denoting message types.
    • Message Length – 2 octets – total length of remaining fields.
    • Message ID – 4 octets – unique number generated by advertising router.
  • Hello message format:
    • Message type in header is set to 0x100
    • Hello TLV type – 2 octet – UFxxxxx. ‘U’ bit as in msg type. ‘F’(Forward) bit is used only when U bit is=1. When F=0 , it implies don’t forward unknown TLV. When set, it implies forward.
    • Hello TLV Length – 2 octets – length of remaining fields.
    • Hold time – 2 octets – lower of values are negotiated with neighbor. JUNOS default: 15 secs.
    • Flags – 2 octets- first 2 bits are used.
      • T bit – set to 1 if targeted hello
      • R bit – set to 1 when local router is requesting neighbor to respond with targeted.
    • Optional TLVs – JUNOS uses ‘IPv4 transport address’ TLV and ‘sequence number’ TLV.
      • Transport add. TLV used to allow other end router to use specified address for LDP. By default loopback address is used. If this TLV is absent, other end uses SRC IP.
      • Sequence number TLV used to alert other end router that config change has happened.

<From traceoptions>

LDP sent UDP PDU 2.2.2.2 -> 1.1.1.1 (lo0.0)

ver 1, pkt len 42, PDU len 38, ID 2.2.2.2:0

Msg Hello (0x100), len 28, ID 62

TLV HelloParms (0x400), len 4

Hold time 45, flags <Targ> (0x8000)

TLV XportAddr (0x401), len 4

Address 2.2.2.2

TLV ConfSeq (0x402), len 4

Sequence 2

  • LDP Initialization message format:
    • After transport and label space of LDP routers are determined by hello messages, LDP session is formed between routers using transport address. TCP connection is established using port number 646.
    • Higher router-ID node (‘active node’) sends LDP initialization message to its peer ( ‘passive’ )
    • Message type in header is set to 0x200
    • Session TLV type: U and F bit set to 0.
    • Session TLV length: Remaining field length.
    • Protocol version: set to LDP version 1
    • Hold time: Amount of hold time requested by sender. Lower value is negotiated. Junos by default uses 30 sec. Loss of valid neighbor (using 15sec hold time) result in loss of session.
    • Flags – 1 octet – First two bits are used.
      • ‘A’ bit : set to 0 by default: Downstream unsolicited. Set to 1 for on-demand.
      • ‘D’ bit: set to 0 by default to indicate loop detection is not enabled.
    • Path vector limit: Used to limit the number of hops for loop detection. Set to 0x00
    • Maximum PDU length: JUNOS uses 4096 by default. Lower value is negotiated.
    • Receiver LSP ID: set to the LSP ID of receiving router.
    • Fault tolerant TLV type: Junos uses this TLV by default to support graceful restart. U and F bit are set to 1 and 0.
    • FT reconnect time: amount of time sending router maintains control state of restarting LSR
    • FT recovery time: set to 0 to indicate sending router will not maintain forwarding state during restart event.

LDP sent TCP PDU 2.2.2.2 -> 1.1.1.1 (none)

ver 1, pkt len 52, PDU len 48, ID 2.2.2.2:0

Msg Initialization (0x200), len 38, ID 64

TLV SesParms (0x500), len 14

Ver 1, holdtime 30, flags <> (0x0)

vect_lim 0, max_pdu 4096, id 1.1.1.1:0

TLV GracefulRestartParms (0x8503), len 12

Reconnect time 0 ms, recovery time 0 ms

  • Keep alive messages are sent every (Holdtime/3) seconds if no other messages are sent during that period. For keepalive, message type is set to 0x201. No other TLVs.
  • Exchanging information across a LDP session:
    • All LDP enabled interfaces are advertised to neighbors using “LDP address message” (msg type:0x300) Withdrawn, if any, using “LDP address withdraw message” (msg type:0x301)
    • Labels are exchanged via “Label mapping message” (msg type:0x400) and withdrawn via “Label withdraw message” (msg type:0x402)
    • FEC (Forwarding equivalence class) is a prefix that is mapped by egress router to an LSP.
    • By default, JUNOS advertise only 32-bit loopback address as FEC.
    • Routes are placed in inet.3 routing table.
    • LDP relies on loop prevention mechanisms of networks IGP.
    • When a router receives label mapping message from a neighbor, it adds the label information to local database and allocates local label and advertise its own label mapping message to all routers including from where it originally received.
    • Routers use the label advertised by next-hop router which is shortest prefix by IGP.

LDP address message:

LDP sent TCP PDU 2.2.2.2 -> 1.1.1.1 (none)

ver 1, pkt len 36, PDU len 32, ID 2.2.2.2:0

Msg Address (0x300), len 22, ID 66

TLV AddrList (0x101), len 14

Address list, family 1

2.2.2.2

10.1.2.2

10.2.2.2

Label mapping message:

LDP sent TCP PDU 2.2.2.2 -> 1.1.1.1 (none)

ver 1, pkt len 38, PDU len 34, ID 2.2.2.2:0

Msg LabelMap (0x400), len 24, ID 67

TLV FEC (0x100), len 8

Prefix, family 1, 2.2.2.2/32

TLV Label (0x200), len 4

Label 3

Using LDP through RSVP message:

  • When only some part of network is enabled by RSVP for traffic engineering and other regions by LDP, we can make LDP regions to exchange labels by tunneling LDP via RSVP network.
  • Above process is called ‘LDP tunneling’ and two RSVP LSPs has to be established between border routers one on each direction.
  • Set ‘ldp-tunneling’ command on those two LSPs.
  • Make sure LDP is enabled on loopback interfaces so that RSVP LSPs are formed between LP IPs.

 

Advertisements
This entry was posted in jncis, Junos, ldp, mpls, rsvp and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s