View
216
Download
0
Category
Preview:
Citation preview
2ο μέρος - BLabel distribution protocols (LDP, RSVP- GMPLS)
MPLS B-ΠΔΤ 1
MPLS B ΠΔΤ 2-2
Label distribution protocols MPLS requires a set of procedures for the reliable distribution
of label bindings between LSRs. MPLS does not require a single label distribution protocol. LDP is a new signaling protocol. It is used to distribute label
bindings for an LSP associated with a FEC. An alternative method to distributing label bindings is to
extend an existing IP control protocol, such as BGP, PIM, and RSVP, so that it can carry label bindings.
LDP/CR-LDP and RSVP-TE are the most popular label distribution protocols
LSR will run both LDP and RSVP-TE. The two label distribution protocols are not compatible, however. In order to establish an LSP, either LDP or RSVP-TE has to be used.
LDP CR-LDP RSVP RSVP-TE
MPLS B ΠΔΤ 2-3
LDP Label spaces, hello adjacencies and sessions LDP messages and formats
LDP peers
Two LSRs that use LDP to exchange labels and FEC mapping information are known as LPD peers.
Two LDP peers exchange information over an LDP session.
Several different LDP messages have been defined.
MPLS B ΠΔΤ 2-4
Messages Four categories of messages have
been defined, namely: Discovery messages Session messages Advertisement messages Notification messages
MPLS B ΠΔΤ 2-5
Messages Discovery messages provide a mechanism
whereby LSRs indicate their presence by sending a hello message periodically.
Session messages are used to establish, maintain, and terminate an LDP session
Advertisement messages are used to create, change, and delete label mappings to a FEC.
Notification messages are used to provide advisory information and signal error information.
MPLS B ΠΔΤ 2-6
Forwarding equivalent class Each FEC comprises one or more FEC elements. Each FEC element identifies a set of packets
which may be mapped to the corresponding LSP.
FEC element: Address prefix This is the most common type of FEC. It is an address prefix
of any length from 0 to a full address. FEC element: Host address
This type is a full host address. When the traffic is destined to a specific host, an LSP can be created for that host address FEC. It is not used very much.
MPLS B ΠΔΤ 2-7
Label Space Label space
The label space is the set of all labels. There is a common label space for all interfaces where IP packets carry
the shim header (i.e. Packet Over SDH - POS, GbE interfaces) There is a label space per ATM interface, and per frame relay interface.
Per interface label space: The label space is specific to a particular interface, and it is not shared by
other interfaces of the Switch (ATM). Per platform label space:
The same label space is shared by all the interfaces. This is typically the case for non-ATM and non-frame relay links such as: POS and GbE. In these type of links, there is no space for a label and a shim header is used. The shim headers are processed by the same MPLS software, which means that the same label space is used for all these interfaces.
MPLS B ΠΔΤ 2-8
LDP Session An LDP session is set-up between two directly
connected LSRs, to support the exchange of LDP messages between them.
An LDP session between two LSRs is associated with a label space.
MPLS B ΠΔΤ 2-9
LDP SessionLDP sessions between two non-directly connected LSRs. An LDP session maybe desirable between two non-directly connected
LSRs. For instance, two distant LSRs, LSRa and LSRb, may communicate via an
LSP. Label stacking is used as well. LSRa can establish a session to LSRb to exchange labels which are pushed down the stack, per example in MPLS presentation
LDP identifiers This is a six-byte quantity and it is used to identify an LSR label space The first four bytes carry a globally unique value identifying the LSR, such as a 32-bit router
id that has been assigned to the LSR by the AS administrator. The last two octets identify a label space. (If the label space is per platform, then the last
two octets are set to zero.) An LDP id (often referred to as a label space id) is expressed as <LSRid: label space number>
MPLS B ΠΔΤ 2-10
LDP operation LDP runs over TCP/UDP For reliability, an LDP session runs on top of TCP. When multiple LDP
sessions are required between two LSRs, there is one TCP session of each LDP session.
LDP discovery messages (i.e., hello messages), however, run over UDP.
LDP discovery This is a mechanism that enables an LSR to discover potential LDP peers,
i.e., other LSRs, which are directly connected to it. An LSR sends periodically LDP link hellos out of each interface. Hello
packets are sent over UDP addressed to a well-known LDP discovery port for the “all routers on this subnet” group multicast address.
An LDP link hello sent by an LSR carries the LDP Id for the label space the LSR wants to use for the interface, and possibly additional information.
Receipt of an LDP link hello identifies a hello adjacency. For each interface, there is one hello adjacency.
MPLS ΠΔΤ 2-11
Establishing an LDP session The exchange of LDP link hellos between two LSRs, triggers
the establishment of an LDP session. Single link between two LSRs: single hello adjacency and a
single LDP session. Parallel links with per platform label space: as many hello
adjacencies as the number of links, but one LDP session. Parallel links, one with per platform label space, and the
others per interface label space: One session per interface, and one adjacency per session.
MPLS B ΠΔΤ 2-12
Establishing an LDP session -2 The establishment of an LDP session involves the following steps: First, a TCP session is established. Then, an LDP session is initialized, during which the two LSRs negotiate session
parameters, such as: protocol version, label distribution method, timer values, range of VPI/VCI values for ATM, range of DLCI values for frame relay, etc.
Maintaining hello adjacencies An LSR maintains a timer for each hello adjacency, which it restarts each time
it receives a hello message. If the timer expires without receiving a hello message from the peer LSR, the
hello adjacency is deleted. If all hello adjacencies associated with an LDP session are deleted, the LDP session is terminated.
Maintaining LDP sessions An LSR maintains a keepAlive timer for each peer session. The timer is reset each time it receives an LDP PDU (any PDU) from its LDP
peer. If the LDP peer has nothing to send, it sends a keepAlive message
MPLS B ΠΔΤ 2-13
Messages at a glance Notification message: It is used to inform an LDP peer of a fatal
error or to provide advisory information i.e. the outcome of processing an LDP message or the state of an LDP session.
Hello messages: LDP hello messages are exchanged for discovering LDP adjacencies.
Initialisation message: This is the most complex LDP message, and it is used to request the establishment of an LDP session.
Address message and address withdraw message: Before sending label mapping and label request messages, an LSR advertises its interface addresses using the address messages. Previously advertised addresses can be withdrawn using the address withdraw message.
Label mapping message: An LSR uses this message to advertise to its LDP peers a binding of a label to a FEC.
Label request message: An LSR sends a label request message to an LDP peer to request a binding (i.e., mapping) for a FEC.
MPLS B ΠΔΤ 2-14
CR-LDPThe Constrained-based Routing -Label Distribution Protocol (CR-
LDP) CR-LDP is a signalling protocol based on LDP. It is used to set-up a unidirectional point-to-point LSP, referred to as
constrained-routed label switched path (CR-LSP). A CR-LSP is analogous to an ATM point-to-point connection, only it is
unidirectional. A bidirectional LSP is setup by creating two separate LSPs, one in each
direction. An LSP is set-up as a result of the routing information in an IP network
using the shortest path algorithm. A CR-LSP is calculated at the source LSR based on criteria not limited to
routing information, such as explicit routing and QoS-based routing. The route is then signaled to the other nodes along the path. This routing technique is known as source routing.
MPLS B ΠΔΤ 2-15
Example. In this MPLS network, router A wants to set-up a CR-LDP (i.e., a
point-to-point unicast connection) to router G. A calculates a path through the network that
may minimize the number of hops (as in LDP), or it may minimize the total end-to-end delay, or it may maximize throughput, or path is pre-calculated to achieve load-balancing, etc.
It then uses CR-LDP messages to set-up the connection through the MPLS network.
CR-LDPs, therefore, can be used for a variety of reasons, such as: Evenly distribute traffic among links by moving some of the traffic from highly
utilized links to less utilized links (load balancing), create tunnels for MPLS-based VPNs, introduce routes based on a QoS criterion, such as minimum number of hops,
minimum total end to-end delay, and maximum throughput.
MPLS B ΠΔΤ 2-16
CR-LDP features It is based on LDP, and it runs on top of TCP for reliability. The CR-LDP state-machine does not require periodic refreshment. Strict and loose explicit routes
This allows the source node some degree of imperfect knowledge about the network topology
Route pinning Fixes the path through a loosely defined route, so that it does not change when a better
next hop becomes available. Specification of traffic parameters
The peak rate, committed rate, and service granularity can be specified. Policers are also used at the ingress.
CR-LSP preemption If a route for a high-priority CR-LSP cannot be found, existing CR-LSPs with a lower
priority may be re-routed to permit the higher-priority CR-LSP to be established. Resource class
The network operator may classify network resources in various ways. These classes are also known as “colours” or “administrative groups”. When a CR-LSP is established, the resource class it can draw from has to be established.
MPLS B ΠΔΤ 2-17
CR-LSP setup procedure A CR LSP is setup using downstream-on-demand allocation with ordered
control. A request at an ingress LSR to setup a CR-LSP might originate from a
management system or an application. The ingress LSR calculates the explicit route (using information provided
by the management system, or the application, or from a routing table) and creates the label request message.
The explicit route is a series of abstract nodes (nodes or autonomous systems) carried in an explicitly routed type-level scheme (format of LDP messages).
The ingress LSR sends the label request message to the first LSR indicated in the ER-TLV.
The receiving LSR forwards the label request message to the next LSR in the ER-TLV, and so on until the message reaches the egress LSR.
The egress LSR returns a label mapping message that will traverse the path in the opposite direction .
MPLS B ΠΔΤ 2-18
LDP supportCR-LDP requires the following LDP messages: Basic/Extended discovery messages Label request message for downstream on demand with ordered control Label mapping message for downstream on demand with ordered
control Notification messages Withdraw and release messages Loop detection (for loosely routed segments )
MPLS B ΠΔΤ 2-19
Data rates – bandwidth allocation Peak rate: This is the maximum rate expressed in bytes/second at
which traffic is sent to the CR-LDP. The peak rate in CR-LDP is specified in terms of token bucket P. The maximum token bucket size of P is set equal to the peak burst size (PBS), expressed in bytes, and the token bucket is reloaded at the peak data rate (PDR), expressed in bytes/sec.
Committed data rate: The committed rate is the amount of bandwidth allocated to the CR-LSP by the network. The traffic that is sent to the network, which is the output of the token bucket P, is policed using the token bucket C, referred to as the committed token bucket. The maximum size of token bucket C is set equal to the committed burst size (CBS), expressed in bytes, and the token bucket is replenished at the committed data rate (CDR), expressed in bytes/sec.
MPLS B ΠΔΤ 2-20
Data rates – Peak data rate Initially, the token count Tp=PBS. Let PDR = N bytes/sec. Then, every second the token count Tp is
incremented by N if Tp ≤PBS (It should not exceed PBS). When a packet of size B arrives, if Tp-B≥0, then the packet is not in excess
of the peak rate, and Tp =Tp-B. Otherwise, it is in excess of the peak rate. Tp is not decreased. The packet
is a violating packet and it can be marked or dropped.
MPLS B ΠΔΤ 2-21
Data rates – Peak data rate Rate of arrival is temporarily >PDR, packet size ≤PBS Packet 1 goes through because of the token count containing enough
bytes Packet 2 is not as lucky! It’ll be dropped or marked. Tp is not decreased. Packet 3 goes through. The token bucket mechanism permits the peak rate of the source to
exceed temporarily the PDR
MPLS B ΠΔΤ 2-22
Data rates – Committed data rate The committed rate is the amount of bandwidth allocated to the CR-LSP
by the network. As in the case of the peak rate, the committed rate is defined by a token
bucket C with parameters Committed data rate(CDR), expressed in bytes/sec Committed burst size(CBS), expressed in bytes.
Token bucket C is replenished at the rate of CDR, and its maximum size is CBS.
The excess token bucket E is defined by the parameters: committed data rate (CDR), expressed in bytes/sec excess burst size (EBS), expressed in bytes.
Token bucket E is replenished at the rate of CDR and its maximum size is EBS.
MPLS B ΠΔΤ 2-23
Committed and excess token bucket operation Initially, the committed token count Tc = CBS, and the excess token count
Te = EBS. Let CDR = M bytes/sec. Then, every second
Tc is increment by M if Tc <CBS(Should not exceed PBS). Te is increment by M, if Te<EBS(Should not exceed EBS)
When a packet of size B arrives, if Tc-B≥0, then the packet is not in excess of the committed rate, and Tc = Tc - B.
Otherwise, if Te-B≥0, then the packet is in excess of the committed rate, but not in excess of the EBS and Te = Te - B.
Otherwise, it is in excess of both the committed rate and the EBS, and neither Tc or Te are decremented.
MPLS B ΠΔΤ 2-24
FlagsSix flags are defined: Flag F1: corresponds to the PDR Flag F2: corresponds to the PBS Flag F3: corresponds to the CDR Flag F4: corresponds to the CBS Flag F5: corresponds to the EBS Flag F6: corresponds to the weight Each flag indicates whether the value it is associated with is negotiable or not
MPLS B ΠΔΤ 2-25
Frequency and WeightFrequency It specifies at what granularity the CDR allocated to the CR-LSP is made available.
The following frequency code points have been defined: 0 – Unspecified 1 – Frequent
The available rate should average the CDR when measured over any time interval equal to or longer than a small number of shortest packet times at the CDR.
2 - Very Frequent The available rate should average the CDR when measured over any time interval equal to or longer
than the shortest packet time at the CDR. 3-255: ReservedWeight It indicates the weight of the CR-LSP. It is used to determine the CR-LSP’ s
relative share of the excess bandwidth. Weight values are from 1 to 255: 0 means that weight is not applicable.
MPLS B ΠΔΤ 2-26
Class ServicesClass services
Class services can be constructed by appropriately manipulating the traffic parameters, and the token bucket decisions that is passing/dropping/marking a packet.
Below, we give several examples of different class services
Example: Delay Sensitive (DS) service The network commits to deliver with high probability user datagramsat a rate of PDR with minimum delay and delay requirement.
Datagrams in excess of PDR will be discardedTraffic parameters:– PDR=user specified– CDR=PDR– Frequency=Frequent– Dropping action: drop>PDR
MPLS B ΠΔΤ 2-27
RSVPMain features of RSVP (Resource reservation protocol)
RSVP was designed to support the integrated services (intserv) architecture. The intserv architecture was developed by IETF in the mid 1990s with a view
to introducing QoS in the IP network. Intserv was never widely accepted. It has been superceded by the DiffServ
architecture, which has been successfully deployed in the IP network. RSVP is a signaling protocol used for the reliable establishment and
maintenance of resource reservations for both unicast and many-to-many multicast applications
RSVP can be used to carry other types of control information since it is not aware of the content of the RSVP protocol fields.
In view of this, it was proposed to be used in MPLS.
MPLS B ΠΔΤ 2-28
Path and Resv messagesRSVP makes use of two messages: Path: This message originates from the sender and travels to the receiver. Resv: Upon receipt of the Path message, the receiver responds with a
Resv message, which travels on the reverse path of the Path message, and reserves bandwidth on each router along the path.
MPLS B ΠΔΤ 2-29
Service classes in Intserv Guaranteed service: This service provides firm bounds on
the end-to-end queueing delay with no packet loss for all conforming packets.
Controlled-load service: This service provides the user with a QoS that closely approximates the QoS of the best effort service that the user would receive from an unloaded network. Specifically, a user might assume the following: a. A very high percentage of transmitted packets will be successfully
delivered by the network to the receiver. The percentage of packets not successfully delivered must closely approximate the basic packet error rate of the transmission links.
b. The end-to-end delay experienced by a very high percentage of the delivered packets will not greatly exceed the minimum end-to-end delay experienced by any successfully delivered packet.
MPLS B ΠΔΤ 2-30
RSVP - TEMain features of RSVP – TE (traffic engineering) RSVP-TE uses downstream-on-demand label allocation with ordered control
to setup an LSP. An LSP can be setup using the next-hop information in the routing table. RSVP-TE can also setup an explicit route by using a new object, called the
EXPLICIT_ROUTE, which encapsulates the hops that make up the explicit path. Strict or loose routing through an abstract node is permitted.
Setting up an LSP - ingress node: The ingress node sends a Path message with a LABEL REQUEST object. This is a
new object and it indicates that a label binding for the path is requested. If an explicit route is requested, then the EXPLICIT_ROUTE object will be
inserted in the Path message.
MPLS B ΠΔΤ 2-31
RSVP - TESetting up an LSP – next hop node: The Path message is forwarded to the next hop indicated in the routing table for the particular IP
destination address of the receiver, or the next hop indicated in the EXPLICIT_ROUTE object. A node incapable of accepting the new requested LSP sends back a PathErr message.
Setting up an LSP - egress node: The egress LSR (i.e., receiver), responds with an Resv message. A new object called the LABEL object, is inserted in the message which is sent back upstream
towards the sender, i.e., the ingress node, following the inverse path traversed by the Path message.
Setting up an LSP - going upstream: Each node that receives the Resv message with a LABEL object uses that label for
outgoing traffic associated with the LSP. It allocates a new label, places it in the LABEL object of the Resv message and
sends it upstream to the previous-hop node. The LSP is established when the sender receives the Resv message.
MPLS B ΠΔΤ 2-32
RSVP - TEResource reservation RSVP-TE enables the reservation of bandwidth along an LSP using
standard RSVP reservations together with intserv service classes. Resource reservation is optional and LSPs can be setup without
reserving any resources. Such LSPs can be used, for instance, to carry best effort traffic and implement backup paths.
Service classes There is no restriction in RSVP-TE as to which intserv service
classes should be supported. RSVP-TE, however, should support the controlled-load service and the null service.
The null service class is newer service class that was introduced in RSVP in order to support RSVP signaling in the differentiated service (diffserv) architecture.
MPLS B ΠΔΤ 2-33
RSVP objectsThe following five new objects have been introduced to support the functionality of RSVPTE:
LABEL LABEL_REQUEST EXPLICIT_ROUTE RECORD_ROUTE SESSION_ATTRIBUTE LABEL: Three different object types (C-Type field), are
supported namely C-Type 1, C-Type 2 and C-Type 3. C-Type 1 is a label request for generic labels. C-Type 2 and 3 is a label request for ATM labels and frame relay respectively.
The EXPLICIT_ROUTE Object: This object is used to specify the hops in the requested explicit route. Each hop could be a single node or a group of nodes, referred to as an abstract node. For simplicity, RSVP-TE refers to all the hops as abstract nodes, with the understanding that an abstract node could consist of a single node.
The RECORD_ROUTE object: Loops can be detected through the RECORD_ROUTE object. In this object the IP address of each node along the path can be recorded. Also, the labels used along the path can be recorded. The RECORD_ROUTE object can be present in both Path and Rev messages.
MPLS B ΠΔΤ 2-34
Generalized MPLS GMPLS is an extension of MPLS. MPLS was designed originally to introduce label switched
paths into the packet-switched network GMPLS was designed with a view to applying label-
switching techniques to time-division multiplexing (TDM) networks and wavelength routing networks in addition to packet-switching networks.
GMPLS, like MPLS, can be used to setup an LSP through an IP network and other packet-switched networks.
It can also be used to: setup a circuit-switched connection in a SONET/SDH network. setup a lightpath in a wavelength routing optical network.
In GMPLS IP routers, ATM switches, Frame Relay switches, Ethernet switches,
DCSs and OXCs are all treated as a single IP network from the control point of view.
MPLS B ΠΔΤ 2-35
GMPLS interfaces A GMPLS-capable LSR may support the following interfaces:
Packet-switch capable (PSC) interfaces Time-division multiplex capable (TDM) interfaces Lamda switch capable (LSC) interfaces Fiber-switch capable (FSC) interfaces
Packet-switch capable (PSC) interfaces: These are the different interfaces used to receive and transmit packets,
such as IP packets, ATM cells, Frame Relay frames, and Ethernet frames. Forwarding of these packets is based on an encapsulated label, VPI/VCI field, DLCI field.
Time-division multiplex capable (TDM) interfaces: They forward data based on the data’s slot(s) within a frame. This interface
is used in a SONET/SDH DCS. Lamda Switch Capable (LSC) interfaces They forward data from an incoming wavelength to an outgoing
wavelength. This interface is used in OXCs.
Fiber-switch capable (FSC) interfaces They forward data from one (or more) incoming fibers to one (or
more) outgoing fibers. They are used in an OXC that can operate at the level of one (or more) fibers.
MPLS B ΠΔΤ 2-36
Hierarchy in GMPLS These four interfaces form a hierarchy used to support
hierarchical LSPs
An LSP may start and end at a packet switched interface (PSC) . It can be then nested together with other LSPs within an LSP
that starts and ends on a TDM interface, which in turn is nested (together with other) within an LSP that starts and ends on a lamda switched interface (LSC).
MPLS B ΠΔΤ 2-37
Gereralized label format The generalized label request is used to request the
establishment of an LSP.
MPLS B ΠΔΤ 2-38
Gereralized label format Switching Type (8 bits):
It indicates the type of switching that should be performed on a particular link.
This field is needed on links that advertise more than one type of switching capability
Generalized payload identifier (G-PID) - 16 bits: It used to identify the payload carried by an LSP. It is used by the endpoints of the LSP. Some of the values are:
MPLS B ΠΔΤ 2-39
Gereralized label The generalized label Several new forms of labels are required to deal with the
widened scope of MPLS into the optical and time-division multiplexing domains.
The generalized label not only allows for the familiar MPLS-type label that travels in-band with the associated packet, but also it allows for labels which identify time-slots, wavelengths, or fibers.
The generalized label may carry a label that represents: Generic MPLS label Frame Relay label, ATM label A set of time-slots within a wavelength, or fiber A single wavelength within a waveband, or fiber A single waveband within a fiber A single fiber in a bundle
These new forms of labels are collectively referred to as the generalized label.
Since the node using GMPLS knows the type of link used, the generalized label does not contain a type field.
The generalized label is not hierarchical. When multiple level of labels are required, each LSP must be established separately.
MPLS B ΠΔΤ 2-40
Other featuresThe suggested label This is used to provide a downstream node with the upstream
node’s label preference. This permits the upstream node to start configuring its
hardware with the proposed label before the label is communicated by the downstream node. (Useful, if time to configure a label is non-trivial).
It can be over-ridden by the downstream node. Suggested label format: Same as generalized label
The label set
The label set is used to limit the label choice of a downstream node to a set of acceptable labels.
The receiver must restrict its choice of labels to one which is in the label set.
MPLS B ΠΔΤ 2-41
CasesLabel setThere are four cases where a label set is useful in the optical
domain: Case 1: The end equipment is only capable of
transmitting/receiving on a small specific set of wavelengths Case 2: There is a sequence of interfaces which cannot support
wavelength conversion, and require the same wavelength to be used over a sequence of hops, or even the entire path.
Case 3: Limit the number of wavelength conversion along the path.
Case 4: Two ends of a link support different sets of wavelengths
A label set is composed of one or more elements. Each element is referred to as a subchannel identifier and it has
the same format as a generalized label. The information carried in a label set is:
MPLS B ΠΔΤ 2-42
Bi-directional LSPs In MPLS two unidirectional LSPs have to
be established in order to provide bidirectional connectivity. Double latency Twice control overhead Route selection may be complicated
In GMPLS, bi-directional optical LSPs can be set-up
MPLS B ΠΔΤ 2-43
ProtectionProtection information It is used to indicate the required
protection desired for the LSP., i.e., dedicated 1+1, dedicated 1:1, shared 1:N, unprotected.
Protection information also indicates if the LSP is a primary or a secondary LSP.
MPLS B ΠΔΤ 2-44
GMPLS protocols GMPLS is an architecture, and as in
MPLS, it requires a signaling protocol for the reliable distribution of label bindings.
Both CR-LDP and RSVP-TE have been extended to support GMPLS.
IS-IS and OSPF have also been extended to support GMPLS.
Recommended