Fast Reroute Extensions to RSVP-TE for LSP Tunnels
01 May 2005-Vol. 4090, pp 1-38
TL;DR: This document defines RSVP-TE extensions to establish backup label- switched path (LSP) tunnels for local repair of LSP tunnels to allow nodes to implement either method or both and to interoperate in a mixed network.
Abstract: This document defines RSVP-TE extensions to establish backup label-
switched path (LSP) tunnels for local repair of LSP tunnels. These
mechanisms enable the re-direction of traffic onto backup LSP tunnels
in 10s of milliseconds, in the event of a failure. Two methods are
defined here. The one-to-one backup method creates detour LSPs for
each protected LSP at each potential point of local repair. The
facility backup method creates a bypass tunnel to protect a potential
failure point; by taking advantage of MPLS label stacking, this bypass
tunnel can protect a set of LSPs that have similar backup constraints.
Both methods can be used to protect links and nodes during network
failure. The described behavior and extensions to RSVP allow nodes to
implement either method or both and to interoperate in a mixed
network. [STANDARDS-TRACK]
Citations
More filters
06 Oct 2005
TL;DR: This work advocate a complete refactoring of the functionality and proposes three key principles--network-level objectives, network-wide views, and direct control--that it believes should underlie a new architecture, called 4D, after the architecture's four planes: decision, dissemination, discovery, and data.
Abstract: Today's data networks are surprisingly fragile and difficult to manage. We argue that the root of these problems lies in the complexity of the control and management planes--the software and protocols coordinating network elements--and particularly the way the decision logic and the distributed-systems issues are inexorably intertwined. We advocate a complete refactoring of the functionality and propose three key principles--network-level objectives, network-wide views, and direct control--that we believe should underlie a new architecture. Following these principles, we identify an extreme design point that we call "4D," after the architecture's four planes: decision, dissemination, discovery, and data. The 4D architecture completely separates an AS's decision logic from pro-tocols that govern the interaction among network elements. The AS-level objectives are specified in the decision plane, and en-forced through direct configuration of the state that drives how the data plane forwards packets. In the 4D architecture, the routers and switches simply forward packets at the behest of the decision plane, and collect measurement data to aid the decision plane in controlling the network. Although 4D would involve substantial changes to today's control and management planes, the format of data packets does not need to change; this eases the deployment path for the 4D architecture, while still enabling substantial innovation in network control and management. We hope that exploring an extreme design point will help focus the attention of the research and industrial communities on this crucially important and intellectually challenging area.
805 citations
26 Jun 2012
TL;DR: The design of NDN's adaptive forwarding is outlined, its potential benefits are articulated, and open research issues are identified.
Abstract: In Named Data Networking (NDN) architecture, packets carry data names rather than source or destination addresses. This change of paradigm leads to a new data plane: data consumers send out Interest packets, routers forward them and maintain the state of pending Interests, which is used to guide Data packets back to the consumers. NDN routers' forwarding process is able to detect network problems by observing the two-way traffic of Interest and Data packets, and explore multiple alternative paths without loops. This is in sharp contrast to today's IP forwarding process which follows a single path chosen by the routing process, with no adaptability of its own. In this paper we outline the design of NDN's adaptive forwarding, articulate its potential benefits, and identify open research issues.
449 citations
Cites background from "Fast Reroute Extensions to RSVP-TE ..."
...MPLS FRR mechanisms ([52, 50]) are proposed to provide backup paths in MPLS-enabled networks in order to handle failures of specific links....
[...]
01 Oct 2008
TL;DR: This talk presents current plans for GENI, the National Science Foundation's ambitious plan to build a national infrastructure suite to enable research into Network Science and Engineering for future global communications networks, and leaves plenty of time for discussion and brain-storms.
Abstract: This talk introduces GENI, the National Science Foundation's ambitious plan to build a national infrastructure suite to enable research into Network Science and Engineering for future global communications networks. GENI has just entered Spiral 1, a new stage in its development. Early prototyping is now beginning, which will offer illumination into its construction plans and research potential. The first round of software, hardware, and trial facilities are now being built by academic and industrial research teams. This talk presents current plans for GENI, but leaves plenty of time for discussion and brain-storming, both for the eventual infrastructure suite and for prototypes that will be built in the coming year.
381 citations
TL;DR: The notion of software-defined networking (SDN), whose southbound interface may be implemented by the OpenFlow protocol, is explained and architectural design choices for SDN using OpenFlow are pointed out.
Abstract: We explain the notion of software-defined networking (SDN), whose southbound interface may be implemented by the OpenFlow protocol. We describe the operation of OpenFlow and summarize the features of specification versions 1.0–1.4. We give an overview of existing SDN-based applications grouped by topic areas. Finally, we point out architectural design choices for SDN using OpenFlow and discuss their performance implications.
242 citations
Cites methods from "Fast Reroute Extensions to RSVP-TE ..."
...Fast reroute mechanisms, such as the MPLS fast reroute [24] or the IP fast reroute [25] can be implemented with OpenFlow group tables....
[...]
...The second contribution of their work is a protection scheme based on MPLS fast reroute [24]....
[...]
Patent•
AT&T1
TL;DR: In this paper, the authors propose a protocol to route control packets based on address partitioning. But the protocol requires the packet to be sent from the server to the router based on an interface that received the packet from the processor.
Abstract: Methods and apparatus to route control packets based on address partitioning. A disclosed example method includes receiving a packet in a server, determining the packet is a control packet, forwarding the packet to a processor, identifying via the processor an address prefix of the packet, accessing a forwarding table and determining via the processor at least one of a router or an outgoing interface that corresponds to the identified address prefix, transmitting the packet from the processor to the server via the outgoing interface, and statically forwarding the packet from the server to the router based on an interface that received the packet from the processor.
220 citations
References
More filters
01 Mar 1997
TL;DR: This document defines these words as they should be interpreted in IETF documents as well as providing guidelines for authors to incorporate this phrase near the beginning of their document.
Abstract: In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
3,501 citations
01 Sep 1997
TL;DR: RSVP as discussed by the authors is a resource reservation setup protocol designed for an integrated services Internet that provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties.
Abstract: This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties.
2,984 citations
01 Dec 2001
TL;DR: In this paper, the use of RSVP (Resource Reservation Protocol) to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching) is described.
Abstract: This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching) Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702
1,479 citations
01 Jan 1998
TL;DR: In this article, the authors discuss issues that should be considered in formulating a policy for assigning values to a name space and provide guidelines to document authors on the specific text that must be included in documents that place demands on the IANA.
Abstract: Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for the IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned. If the IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA.
536 citations
01 Oct 1998
TL;DR: Many protocols make use of identifiers consisting of constants and other well-known values that must be administered by a central authority to insure that such quantities have consistent values and interpretations in different implementations.
Abstract: Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).
334 citations