12/02/2002 edward qian network protocol software: design and implementation an industrial...

12/02/2002

Edward Qian

Network Protocol Software:Design and Implementation

An Industrial Perspective

12/02/2002Edward Qian 2

Overview: Network Protocols

MPLS with RSVP-TE

Practical Considerations on Protocol Software ImplementationThe requirements for protocol softwareThe design for protocol softwareThe implementation for protocol softwareThe verification for protocol software

Discussions


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

Overview


Overview

MPLS

CLNPIS-IS

PHY

SONET

UTOPIA

ATM

NAT

Ethernet

AAL5

HDLC

PPP

ARPIPICMP

IP

IGMP

IPsecVRRPIS-IS

over IPOSPFTCP UDP

Sockets

RSVPRIP

Sockets

Telnet PPTP BGP TFTPRTP

RTCPDNSSNMP RADIUS L2TPDHCPBootP

Typically a router would be equipped with most of these protocol stacks in it.

RSVP-TE


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



MPLS with RSVP-TE


Discussions


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

service 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 carrier-

grade services (especially important for Voice in convergence IP network) Value-added services (MPLS enabled VPNs, Voice over MPLS, …)


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 Routing Software

PacketForwarding

ATM Control Plan

LabelSwitching

IP Routing Software

LabelSwitching

LabelDistributionSignaling

MPLSIP ATM


MPLS with RSVP-TE

What is a Label?


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


MPLS with RSVP-TE

MPLS Key Concepts (cont’d) Label Distribution/Signaling

Label Distribution Protocolo Provide procedures by which one LSR informs another for the label/FEC bindingo 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


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

RSVP Ext for Security(RFC2747/3097)

RSVP Ext for Refresh Reduction(RFC2961)

RSVP Ext for IP Tunnel(RFC2746)

RSVP-TE(RFC3209)

… …

GMPLS Extensions(draft-ietf-mpls-generalized-rsvp-te-##)


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


MPLS with RSVP-TE

In Backus and Naur Form (BNF)

PATH Message<Path Message> ::= <Common Header>

[ <INTEGRITY> ]<SESSION><RSVP_HOP><TIME_VALUES>

[ <EXPLICIT_ROUTE> ]<LABEL_REQUEST>

[ <SESSION_ATTRIBUTE> ][ <NOTIFY_REQUEST> ] [ <POLICY_DATA> ... ]

<sender descriptor>

<sender descriptor> ::= <SENDER_TEMPLATE><SENDER_TSPEC>[ <ADSPEC> ][ <RECORD_ROUTE> ]

RESV Message<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> ]


MPLS with RSVP-TE

LSP Setup (RSVP-TE Signaling) Label distribution with RSVP-TE signaling Uni-Directional Downstream-on-Demand

R1(Ingress)

R4(Egress)

R2 R3

10.60.0.0/16LSP

R5

R6

40 40 53 53 81 81

PATH(Label Request)

PATH(Label Request)

PATH(Label Request)

RESV(Label 81)

RESV(Label 53)

RESV(Label 40)

RESVCONF RESVCONFRESVCONF


MPLS with RSVP-TE

LSP Setup (RSVP-TE Signaling)With more details

R1 (Ingress) R4 (Egress)R2 R3

10.60.0.0/16

R5

R6

40 40 53 53 81

RESV(Label 81)

RESV(Label 53)

RESV(Label 40)

SO: IPd=10.60.0.0/16, Tunnel ID=12ERO: R1-R2-R3-R4LRO: L3PIDSAO: setup/holding priorities, flag for local protectSTO: sender address, LSP IDRRO: R1

81

ERO: R2-R3-R4RRO: R1-R2

ERO: R3-R4RRO: R1-R2-R3

ERO: R4RRO: R1-R2-R3-R4

LO: Label 81RRO: R4 81

LO: Label 53RRO: R3-R4 53-81

LO: Label 40RRO: R2-R3-R4 40-53-81

RRO: R1-R2-R3-R4 40-53-81

PATH(Label Request)

R3

R2

R4

ERO:

PATH(Label Request)

R4

R3

ERO:

PATH(Label Request)

R4

ERO:

R4

RRO:

81

LO:

R3

R4

RRO:

53

LO:

R3

R2

R4

RRO:

40

LO:

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

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

SO: Session ObjERO: Explicit Route ObjLRO: Label Request ObjLO: Label ObjSAO: Session Attribute ObjSTO: Sender Template ObjRRO: Record Route Obj

SO: Session ObjERO: Explicit Route ObjLRO: Label Request ObjLO: Label ObjSAO: Session Attribute ObjSTO: Sender Template ObjRRO: Record Route Obj


MPLS with RSVP-TE

LSP Setup (RSVP-TE Signaling)With more details

81

R1 (Ingress) R4 (Egress)R2 R310.60.0.0/16

Tunnel (ID=12)

R5

R6

40 53 81


MPLS with RSVP-TE

Data Forwarding

Edge LSR(Ingress)

Edge LSR(Egress)

LSR LSR

Label

40 5340 53 81 81

40 53SWAP 81SWAP

L2 header

IP

PUSH40

POP81

81


MPLS with RSVP-TE

Path Protection

Setup Primary Tunnel

Setup Detour Tunnel

Detour LSP

PLR(Point of Local Repair)

MP(Merge Point)Avoid NodeIngress Egress

PATH for Primary LSP

RESV for Primary LSPPATHd for Detour LSP RESVd for Detour LSP

RESV for Primary LSP

Primary LSP


MPLS with RSVP-TE

Path Protection

Detour LSP


MP(Merge Point)Avoid NodeIngress EgressPrimary LSP



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


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

Requirements for Protocols



MPLS with RSVP-TE

Practical Considerations on Protocol Software ImplementationThe requirements for protocol software

The design for protocol software The implementation for protocol software The verification for protocol software

Discussions


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 (see a generic reference design, next …)

Design for Protocols


A generic reference design

Design for Protocols

Configuration Management

MPLSLabel Manager (LM)

RSVP-TE

Routing Protocols(OSPF/IS-IS/BGP)

with RoutingTable Manager

(RTM)

IP Stack

ForwardingInformation Base

(FIB)

Traffic EngineeringDatabase (TED)

MPLS Switch HW-label operation

- control flow

Device Drivers

Embedded control softwarerunning on RTOS

Data

Control

Data



MPLS with RSVP-TE

Practical Considerations on Protocol Software ImplementationThe requirements for protocol softwareThe design for protocol software

The implementation for protocol software The verification for protocol software

Discussions


General Considerations 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)

Implementation for Protocols



MPLS with RSVP-TE

Practical Considerations on Protocol Software ImplementationThe requirements for protocol softwareThe design for protocol softwareThe implementation for protocol software

The verification for protocol software

Discussions


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

Verification for Protocols



MPLS with RSVP-TE


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

Computer Networks (like this course) Distributed Systems Operating Systems (better yet Real-Time OS) Data Structures and Algorithms Concurrent Programming Software Engineering/Processes

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

Discussions


The Dao of Design

The Tao of Design

12/02/2002 edward qian network protocol software: design and implementation an industrial...

Documents

network protocol software

protocol softwarethe

network protocolsmpls

network technology

ip network qos

multiprotocol label

ip core network evolution

way network devices