Transcript MPLS with RSVP-TE

Network Protocol Software:
Design and Implementation
An Industrial Perspective
Edward Qian
12/02/2002
Overview: Network Protocols
MPLS with RSVP-TE
Practical Considerations on Protocol Software Implementation
The requirements for protocol software
The design for protocol software
The implementation for protocol software
The verification for protocol software
Discussions
Edward Qian
12/02/2002
2
Overview
 Network Protocols: the communication language that
network devices talk to each other at a specific layer

One example: Even since the Internet was developed, two
camps of religious debates over “datagram” vs. “virtual circuit”
 Connectionless IP carries a transmission connection (TCP)
 Connected-oriented ATM or MPLS needs its connectionless routing to
guide the way in setting up a connection.
 Industry actually accepted both.

No matter which way network devices communicate, they
communicate with protocols.
 We take MPLS technology and its protocols as the
example for this lecture
Edward Qian
12/02/2002
3
Overview
 Typically a router would be equipped with most of these protocol
stacks in it.
RSVP-TE
Edward Qian
12/02/2002
4
Overview
 Almost all network protocols are implemented as software (stacks)
 Software design and implementation of network protocols play a
crucial roles in developing network systems/devices
 The early buggy implementation of OSI protocol stacks burned its users, so it stuck
even though it’s got later improvement
 Relatively compare with the TCP/IP as part of free Berkeley UNIX, it gained user
acceptance quickly, got better improvement, then wider user acceptance
Edward Qian
12/02/2002
5
Overview: Network Protocols
 MPLS with RSVP-TE
Practical Considerations on Protocol Software Implementation
The requirements for protocol software
The design for protocol software
The implementation for protocol software
The verification for protocol software
Discussions
Edward Qian
12/02/2002
6
MPLS with RSVP-TE
 What is MPLS?
 Multi-protocol Label Switching – a network technology defined within IETF
body
 IP-based routing but connect-oriented label-based switching of packet.
 MPLS borrows concepts from other networking protocols such as ATM and
IP – which makes it well suited for a lot of today’s networks need.
 Why uses MPLS?
 ATM to IP core network evolution (one common MPLS core for multiservice accesses)
 Next-Gen Convergence Network (voice, video and data)
 Stringent SLA delivery in an IP network (QoS offering with DiffServ)
Control of: end-to-end delay, jitter, packet loss, packet order, etc.
 Traffic engineering with path protection and fast re-route to provide carriergrade services (especially important for Voice in convergence IP network)
 Value-added services (MPLS enabled VPNs, Voice over MPLS, …)
Edward Qian
12/02/2002
7
MPLS with RSVP-TE
 MPLS is a hybrid model adopted by IETF to make use of the best
properties in both packet routing and circuit switching.
IP
Edward Qian
12/02/2002
MPLS
ATM
IP Routing Software
IP Routing Software
ATM Control Plan
Packet
Forwarding
Label
Switching
Label
Switching
Label
Distribution
Signaling
8
MPLS with RSVP-TE
What is a Label?
Edward Qian
12/02/2002
9
MPLS with RSVP-TE
 MPLS Key Concepts

FEC (Forwarding Equivalence Class)
 A group of IP packets which are forwarded in the same manner (e.g., over the same path,
with the same priority and the same label)

Label
 A short fixed length identifier which is used to identify a FEC
 Label Stacking – Tunneling
 Label Swapping – Looking up the incoming label to determine the outgoing label,
encapsulation and port.




Label Switching Router (LSR) – An MPLS capable router.
Label Edge Router (LER) – An MPLS capable router at the endpoint of LSP.
Label Switched Path (LSP) – Path through one or more LSRs for a particular
FEC
Data Forwarding
 Label encapsulation
 Label operations: PUSH, SWAP and POP, Penultimate-hop Popping
Edward Qian
12/02/2002
10
MPLS with RSVP-TE
 MPLS Key Concepts (cont’d)

Label Distribution/Signaling
 Label Distribution Protocol
o Provide procedures by which one LSR informs another for the label/FEC binding
o LDP, CR-LDP/RSVP-TE, MPLS-BGP

Path Protection
 Protection Switching (Head-End Repair)
 Fast Re-Routing (Local Repair)
 Crankback of Setup failure

Traffic Engineering
 L-LSPs and E-LSPs
 Routing Protocols Traffic Engineering Extensions
o Extensions to Routing Protocols – Existing routing protocols can be extended to distribute traffic
engineering information
Edward Qian
12/02/2002
11
MPLS with RSVP-TE
 RSVP-TE

What is RSVP-TE
 Use of RSVP protocol with certain traffic engineering extensions to setup
MPLS LSP.

The relationship between RSVP-TE and RSVP
RSVP-TE (RFC3209), RSVP(RFC2205)
 Syntactically, RSVP-TE as a protocol is an extension to RSVP
 Semantically, RSVP-TE is used for MPLS LSP setup as a label distribution protocol which is
very differently from the original RSVP as mainly for resource reservation for IntServ.
RSVP
(RFC2205)
RSVP for IntServ
(RFC2210/11/12)
More RSVP Ext for IntServ
Edward Qian
12/02/2002
RSVP Ext for IP Tunnel
(RFC2746)
RSVP Ext for Security
(RFC2747/3097)
RSVP Ext for Refresh Reduction
(RFC2961)
RSVP-TE
(RFC3209)
GMPLS Extensions
(draft-ietf-mpls-generalized-rsvp-te-##)
……
12
MPLS with RSVP-TE
 RSVP-TE

Main Functions






Signaling for path (with explicit route, crankback, refresh, auto-restart)
Label Request and Distribution
Resource Reservation (with Traffic Engineering)
Keep Alive (RSVP Hello)
Label Distribution/Signaling
How to use RSVP-TE?
 Signaling a path for LSP. Along the path peer nodes are expected to be RSVP-TE
capable
 Explicit source routing as path selection (ERO extension)
 Request and Distribute labels (LRO and LO extension)
 More traffic engineering parameters (SAO extension)
 Fast peer failure detection (HELLO extension)
 And more ……
Edward Qian
12/02/2002
13
MPLS with RSVP-TE
 RESV Message
 PATH Message
<Path Message> ::=
<Common Header>
[ <INTEGRITY> ]
<SESSION>
<RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<Resv Message> ::=
<Common Header>
[ <INTEGRITY> ]
<SESSION>
<RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ]
[ <SCOPE> ]
[ <NOTIFY_REQUEST> ]
[ <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> ]
<sender descriptor> ::= <SENDER_TEMPLATE>
<SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
In Backus and Naur Form (BNF)
Edward Qian
12/02/2002
14
MPLS with RSVP-TE
 LSP Setup (RSVP-TE Signaling)



Label distribution with RSVP-TE signaling
Uni-Directional
Downstream-on-Demand
R6
40
R1
(Ingress)
40
PATH
(Label Request)
53
R2
LSP
53
PATH
(Label Request)
81
81
10.60.0.0/16
R3
PATH
R4
(Egress)
(Label Request)
RESV
RESV
RESV
(Label 40)
(Label 53)
(Label 81)
RESVCONF
RESVCONF
RESVCONF
R5
Edward Qian
12/02/2002
15
MPLS with RSVP-TE
Note: At each node, ERO list is popped till the bottom;
RSVP uses NH IP address to query routing table for NH interface;
and then encap to IP packet destined to Egress with router alert option
 LSP Setup (RSVP-TE Signaling)
With more details
ERO:
SO: IPd=10.60.0.0/16, Tunnel ID=12
R2
ERO: R1-R2-R3-R4
R3
LRO: L3PID
R4
SAO: setup/holding priorities, flag for local protect
STO: sender address, LSP ID
RRO: R1
(Label 40)
Edward Qian
12/02/2002
R4
ERO: R3-R4
RRO: R1-R2-R3
R2
RESV
(Label 53)
ERO: R4
RRO: R1-R2-R3-R4
PATH
(Label Request)
53
53
LO: Label 40
RRO: R2-R3-R4
40-53-81
RRO: R1-R2-R3-R4
40-53-81
SO: Session Obj
ERO: Explicit Route Obj
LRO: Label Request Obj
LO: Label Obj
SAO: Session Attribute Obj
STO: Sender Template Obj
RRO: Record Route Obj
R3
R4
PATH
(Label Request)
40
40
RESV
ERO:
ERO: R2-R3-R4
RRO: R1-R2
PATH
R1 (Ingress)
ERO:
(Label Request)
81
81
10.60.0.0/16
R3
RESV
(Label 81)
LO: Label 53
RRO: R3-R4
53-81
LO: Label 81
RRO: R4
81
LO:
LO:
LO:
40
53
81
RRO:
RRO:
RRO:
R2
R3
R4
R3
R4
R4
R5
R4 (Egress)
R6
16
MPLS with RSVP-TE
 LSP Setup (RSVP-TE Signaling)
With more details
Tunnel (ID=12)
40
R1 (Ingress)
53
R2
81
R3
81
10.60.0.0/16
R4 (Egress)
R6
R5
Edward Qian
12/02/2002
17
MPLS with RSVP-TE
 Data Forwarding
Edge LSR
(Ingress)
LSR
LSR
Edge LSR
(Egress)
81
40
40
PUSH
40
53
SWAP
53
53
81
SWAP
81
81
POP
81
40
IP
L2 header
Edward Qian
12/02/2002
Label
18
MPLS with RSVP-TE
 Path Protection
Setup Primary Tunnel
PATH for Primary LSP
Ingress
PLR
(Point of Local Repair)
RESV for Primary LSP
Primary LSP
Avoid Node
Setup Detour Tunnel
PATHd for Detour LSP
MP
(Merge Point)
Egress
RESV for Primary LSP
RESVd for Detour LSP
Detour LSP
Edward Qian
12/02/2002
19
MPLS with RSVP-TE
 Path Protection
Ingress
PLR
(Point of Local Repair)
Primary LSP
Avoid Node
MP
(Merge Point)
Egress
Detour LSP
Edward Qian
12/02/2002
20
MPLS with RSVP-TE
 Path Protection
Ingress
PLR
(Point of Local Repair)
Primary LSP
Avoid Node
MP
(Merge Point)
Egress
Detour LSP
Edward Qian
12/02/2002
21
Overview: Network Protocols
MPLS with RSVP-TE
Practical Considerations on Protocol Software Implementation
The requirements for protocol software
The design for protocol software
The implementation for protocol software
The verification for protocol software
Discussions
Edward Qian
12/02/2002
22
Requirements for Protocols
 General Considerations








Communication needs for inter-networking …
As “signaling”, for connected-oriented networks
As “routing”, for connectionless networks
Layered, so we call a protocol stack
Peer-to-peer, client-server, end-to-end …
control or data (layers, stacks, planes…)
Scalability
Third-party protocol stack purchasing; In-house development vs. outsourcing
 Our Example






Edward Qian
12/02/2002
Label switched router
RSVP-TE as the signaling protocol for label distribution and managing LSPs/Tunnels
Perform label pushing/swapping/popping operation in data forwarding (switching)
Connection-oriented traffic engineered tunnels for voice/video streams
Carrier-grade high availability with MPLS path level protection
Taking advantage of third-party protocol stack to improve time-to-market and development cost
23
Overview: Network Protocols
MPLS with RSVP-TE
Practical Considerations on Protocol Software Implementation
The requirements for protocol software
The design for protocol software
The implementation for protocol software
The verification for protocol software
Discussions
Edward Qian
12/02/2002
24
Design for Protocols
 General Considerations





Modular Design, Separation of Concerns
Distributed vs. Centralized
Redundancy
Certain extensions to the protocol (BNF as notation for protocol message)
Evaluation and selection of the third-party protocol stack, stack porting and integration
to your system as a part of your design
 Our Example

Edward Qian
12/02/2002
(see a generic reference design, next …)
25
Design for Protocols
 A generic reference design
Configuration Management
Embedded control software
running on RTOS
Routing Protocols
(OSPF/IS-IS/BGP)
with Routing
Table Manager
(RTM)
MPLS
Label Manager (LM)
Traffic Engineering
Database (TED)
RSVP-TE
Forwarding
Information Base
(FIB)
IP Stack
Device Drivers
Control
Data
Edward Qian
12/02/2002
MPLS Switch HW
-label operation
- control flow
Data
26
Overview: Network Protocols
MPLS with RSVP-TE
Practical Considerations on Protocol Software Implementation
The requirements for protocol software
The design for protocol software
The implementation for protocol software
The verification for protocol software
Discussions
Edward Qian
12/02/2002
27
Implementation for Protocols
 General Considerations













Edward Qian
12/02/2002
Real-time
Protocol stack outsourcing, third-party stack source code evaluation
Porting
Integrating
OS dependency
Multi-tasking, preemption, critical region, priority inversion, starvation, dead-lock
Memory management (not too frequent dynamic allocation…buffer ownership)
Performance issues
Timer services
Flexibility for PDU framing and manipulations
Extensibility
APIs (loosely or tightly coupled)
Network Order (Big Endian)
28
Overview: Network Protocols
MPLS with RSVP-TE
Practical Considerations on Protocol Software Implementation
The requirements for protocol software
The design for protocol software
The implementation for protocol software
The verification for protocol software
Discussions
Edward Qian
12/02/2002
29
Verification for Protocols
 General Considerations





Functional behavior
Protocol conformance and compliance
Interoperability with other vendor devices in the networks
Performance test and the room for improvement
Stress test in extreme situation
 Our Example





Edward Qian
12/02/2002
Follow RFCs and I-Ds for all functional specs that you claim to be conformed with for
those MPLS/RSVP-TE related features
For configuration, certain MIBs to be supported and extended, able to set/get and
provide required traps.
People often quote that functioning first, then performance…you will find that you have
to pay a high price to alter your design due to some key performance issues.
You will also learn some painful lessons that your “free-style” coding habit caused the
system failed at extreme large connections…you may have memory leak.
……
30
Overview: Network Protocols
MPLS with RSVP-TE
Practical Considerations on Protocol Software Implementation
The requirements for protocol software
The design for protocol software
The implementation for protocol software
The verification for protocol software
 Discussions
Edward Qian
12/02/2002
31
Discussions
 Qualification as a Protocol Designer and Software Engineer





General software engineering principle and practice
Working knowledge of network architecture and protocols
Real-time embedded software design skill (RTOS, concurrent programming …)
In-depth understanding of modern network devices (routers, switches,
multiplexers, as well as the state-of-art network processors), and their
management.
C/C++
 Recommended Courses






Edward Qian
12/02/2002
Computer Networks (like this course)
Distributed Systems
Operating Systems (better yet Real-Time OS)
Data Structures and Algorithms
Concurrent Programming
Software Engineering/Processes
32
Discussions
 Loose the other end

Protocols are evolving
 As in computing, IBM’s PL/I as the language of the future  DoD’s Ada  …?…
 now we are enjoying (or suffering) with C/C++  now here comes a cup of
Java…
 ISDN once was believed as the “telecom GUT” the way people (with such end
devices) communicate through the whole world  ATM (B-ISDN)  IP 
Converged+MPLS  …future? (or back to future with the good old Ethernet and
SONET?)…
 Follow the money or the technology?

Engineers facing the challenges and even paradigm shift
 Sharpening your skills (not only the technical side…)
 Be brave to lead or at least to adaptively follow
 … … be flexible
Edward Qian
12/02/2002
33
The Dao of Design
The Tao of Design
Edward Qian
12/02/2002
34