200 likes | 214 Vues
The paper discusses motivations, requirements, and functions of the RSVP-TE network simulator for MPLS networks, GMPLS networks, and more, with a focus on MPLS node implementation and simulation functionalities.
E N D
Overview of RSVP-TE Network Simulator: Design and Implementation D.Adami, C.Callegari, S.Giordano, F.Mustacchio, M.Pagano, F.Vitucci Dipartimento di Ingegneria dell’Informazione: Elettronica, Informatica, Telecomunicazioni Università di Pisa Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
Outline • Motivations and Requirements • a MPLS Node Simulator (MNS) based on the Constrained Routing – Label Distribution Protocol (CR-LDP) is available in NS2 but….. • MPLS node implementation • strict distinction between control and data plane • RSVP-TE\ns module • RSVP-TE enhancements for LSP handling • simulator functions • Functional validation test Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
Motivations • A MPLS Network Simulator (MNS) is available in the Network Simulator 2 (NS2) • developed at Chungnam National University, Korea • based on the Constrained Routing – Label Distribution Protocol (CR-LDP) • But … • IETF RFC 3468 states: • “Multiprotocol Label Switching (MPLS) Working Group within the IETF focus its efforts on “Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for Label-Switched Paths (LSP) Tunnels” (RFC 3209) as the MPLS signalling protocol for traffic engineering applications and undertake no new efforts relating to “Constraint-Based LSP Setup using Label Distribution Protocol (LDP)” (RFC 3212)”. • CCAMP Working Group survey • A survey of GMPLS implementations was published in June 2002. It includes responses from 22 different implementers. Twenty-one of 22 implementations include the GMPLS signalling based on RSVP-TE while only 3 include signalling based on CR-LDP. Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
Motivations • RSVP-TE Network Simulator will be useful to assess the feasibility of innovative mechanisms in different network scenarios: • MPLS networks (MPLS Working Group) • Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE • Extensions to RSVP-TE for Point to Multipoint TE LSPs • DiffServ-aware MPLS networks (MPLS Working Group) • RFC 3568 defines the concept of Classtype but no RSVP-TE enhancements have been standardized yet to support such an information • GMPLS networks (CCAMP Working Group) • RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
Requirements • Overall design requirements • Standard compliance: with respect to IETF Standardization documents(e.g RSVP-TE RFC 3209) • Extensibility: enhancements in the signalling protocol and in the control plane mechanisms should be easily introduced in the simulator • Modularity: it should be possible to combine different modules implementing distinct functionalities (e.g. use of different scheduling algorithms) • Open source code:Network Simulator version 2 Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
Destination Source MPLS node implementation • To develop a full comprehensive simulation environment for MPLS networks the following functionalities are required: • Data plane mechanisms (label swapping, traffic mapping, etc.) • Control plane mechanisms (MPLS signalling protocol: RSVP-TE o CR-LDP) Label Switched Path (LSP) 1 Label Switched Path (LSP) 2 Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
MPLS node implementation in the NS2 simulator Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
MPLS node implementation: control plane Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
MPLS node implementation: data plane Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
RSVP-TE\ns module • RSVP-TE object added or modified in the PATH message: • SESSION • LABEL_REQUEST • SENDER_TEMPLATE • SENDER_TSPEC • EXPLICIT ROUTE OBJECT (ERO) • RECORD ROUTE OBJECT (RRO) • SESSION_ATTRIBUTE Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
RSVP-TE\ns module • RSVP-TE object added or modified in the PATH message: • SESSION • LABEL_REQUEST • SENDER_TEMPLATE • SENDER_TSPEC • EXPLICIT ROUTE OBJECT (ERO) • RECORD ROUTE OBJECT (RRO) • SESSION_ATTRIBUTE Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
RSVP-TE\ns module • RSVP-TE object added or modified in the RESV message: • SESSION • FLOW_SPEC • FILTER_SPEC • STYLE • LABEL • RECORD ROUTE OBJECT (RRO) Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
Simulator functions • LSP establishment • Commands: <Ingress-LER> create-erlsp-rsvpte <Egress-LER> <sessionID> <FlowID> <TunnelID> <er> <Ingress-LER> create-erbwlsp-rsvpte <Egress-LER> <sessionID> <FlowID> <TunnelID> <rate> <bucket> <ttl> <er> • Action: • a PATH message is sent by the Ingress Label Edge Router (LER) towards the Egress LER • An explicit route could be specified by means of the ERO Object • After the Egress LER receives the PATH message, a RESV message is sent upstream • The RESV message is processed by each Label Switched Router (LSR) along the path, which, in turn, performs label allocation and optionally resource reservation Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
Simulator functions • Mapping traffic flows to a LSP: • Command: <Ingress-LER> bind-flow-LSP <Dest Address> <FlowID> <TunnelID> • Action: • Traffic flow is mapped onto the LSP • LSP release: • Command: <Ingress-LER> release-LSP <SessionID> <FlowID> • Action: • a PATH_ERR message is sentby the Ingress Label Edge Router (LER) towards the Egress LER • labels and resources are releasedalong the PATH Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
Simulator functions • Failure handling • Command: <Upstream node> break-link <Downstream node> • Action: • a PATH_ERR message is sentby the LSR (Upstream node) towards the Ingress LER for each LSP • In turn, the Ingress LER sends a PATH_TEAR message to release resources • a RESV_ERR message is sentby the LSR (Upstream node) towards the Egress LER for each LSP • In turn, the Egress LER sends the corresponding RESV_TEAR message to release resources Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
Functional validation test • Objective • to assess LSP establishment, flow mapping and failure handling in the RSVP-TE Network Simulator Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
Functional validation test • Objective • to assess LSP establishment, resource allocation, traffic engineering mechanisms and flow mapping in the RSVP-TE Network Simulator Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
Functional validation test (NAM animation) Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
Conclusions • A full comprehensive MPLS network simulation environment based on the RSVP-TE signalling protocol has been developed • Thank to its modularity and extensibility this simulation environment could be useful to speed-up the design, development and deployment of enhanced (G)MPLS networks • The software is available on the TlcNetGroup software repository at the site: wwwtlc.iet.unipi.it Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005
Questions? Thank you Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005