David Clark. Policy Routing in Internet Protocols. Internet Engineering Task Force, May 1989. RFC 1102.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....the locations and interconnections among servers are an image of the underlying network topology. This assumption significantly reduces the parameter space in the simulation. Nonetheless, this is a reasonable assumption, since it reflects the structure of domains that characterize the Internet [9]. In addition to simulating the various multi server architectures, we simulate a single server, centralized architecture. The centralized architecture serves as a reference architecture that we use as a baseline for our comparisons; where the centralized architecture performs as well as or ....

D. Clark. Policy routing in internet protocols. Internet Requests For Comments (RFC) 1102, May 1989.

....fields contain the IP addresses of the sampled data. 4.3 Policy Routing RON allows users or administrators to define the types of traffic allowed on particular network links. In traditional Internet policy routing, type is typically defined only by the packet s source and destination addresses [4]; RON generalizes this notion to include other information about the packet. RON separates policy routing into two components: classification and routing table formation. When a packet enters the RON, it is classified and given a policy tag; this tag is used to perform lookups in the appropriate ....

CLARK,D.Policy Routing in Internet Protocols. Internet Engineering Task Force, May 1989. RFC 1102.

....fields contain the IP addresses of the sampled data. 4.3 Policy Routing RON allows users or administrators to define the types of traffic allowed on particular network links. In traditional Internet policy routing, type is typically defined only by the packet s source and destination addresses [4]; RON generalizes this notion to include other information about the packet. RON separates policy routing into two components: classification and routing table formation. When a packet enters the RON, it is classified and given a policy tag; this tag is used to perform lookups in the appropriate ....

CLARK, D. Policy Routing in Internet Protocols. Internet Engineering Task Force, May 1989. RFC 1102.

....policy that Only students in the Computer Science department are allowed to use MIT s connection to the Internet2. Other administrators may wish to apply different, less advantageous, policies, of course. On the Internet, type is typically defined only by its source and destination addresses [8]; RON extends this notion to a more general notion of packet type. RON separates policy routing into two components: Classification and routing table formation. Packets are given a policy tag when they enter the RON, and this policy tag is used to perform lookups in the proper set of routing ....

David Clark. Policy Routing in Internet Protocols. Internet Engineering Task Force, May 1989. RFC 1102.

....scheme that can enhance the ability of organizations to implement traffic policies. Policy routing, as it is known, is the ability to make routing decisions based upon the source or type of traffic, not just its destination address. Policy routing has been considered by the IETF as early as 1989 [2], but its use in backbone routers have been scarce because of the increased CPU load it frequently imposes. RONs interact with network policies in two ways. Because RONs are deployed only between small groups of cooperating entities who have already purchased the Internet bandwidth they use, RONs ....

CLARK, D. Policy Routing in Internet Protocols. Internet Engineering Task Force, May 1989. RFC 1102.

....that provide user traffic with the requested service within the constraints stipulated by the domains transited. In this document, we specify the protocols that compose IDPR, and we recommend ways to use these protocols. For more information about policy routing and its role in the Internet, see [1] [7] With IDPR, we introduce a new network layer Internet protocol based on source specified routing between administrative domains and a new Internet addressing structure based on an administrative domain hierarchy. However, for IDPR version 1, we recommend implementing a proper subset of the ....

....distributed by domains to synthesize acceptable policy routes. However, source policy representation may be local to each domain, as domains do not distribute source policy information externally. We have elected to represent transit policies using a variant of Clark s policy term notation[1]. Each policy term (PT) takes the form of a collection of sets as follows: f( H 11 ; AD 11 ; s 11 ) H 1f 1 ; AD 1f 1 ; s 1f 1 ) Hn1 ; ADn1 ; sn1 ) H nfn ; AD nfn ; s nfn ) g : The set of groups of applicable source and destination hosts and domains. Each host ....

D. Clark. Policy routing in internet protocols. RFC 1102. May 1989.

....all domains, an inter domain routing protocol is executed that provides routes between source and destination nodes in different domains. This protocol must satisfy various constraints: 1) It must satisfy policy constraints, which are administrative restrictions on the inter domain traffic [6, 10, 7, 3]. Policy constraints are of two types: transit policies and source policies. The transit policies of a domain A specify how other domains can use the resources of A (e.g. 0.01 per packet, no traffic from domain B) The source policies of a domain A specify constraints on traffic originat ing ....

.... as back doors ) 4) Inter domain routing protocols must automatically adapt to link cost changes, node link failures and repairs including failures that partition domains [13] A simple (or straightforward) approach to interdomain routing is domain level source routing with link state approach [6, 3]. In this approach, each router 1 maintains a domain level view of the internetwork, i.e. a graph with a vertex for every domain and an edge between every two neighbor domains. Policy and ToS information is attached to the vertices and the edges of the view. When a source node needs to reach a ....

[Article contains additional citation context not shown here]

D.D. Clark. Policy routing in Internet protocols. Request for Comment RFC-1102, Network Information Center, May 1989.

....all domains, an inter domain routing protocol is executed that provides routes between source and destination nodes in different domains. This protocol must satisfy various constraints: ffl It must satisfy policy constraints, which are administrative restrictions on the inter domain traffic [6, 7, 4]. Policy constraints are of two types: transit policies and source policies. The transit policies of a domain U specify how other domains can use the resources of U (e.g. 0.01 per packet, no traffic from domain V ) The source policies of a domain U specify constraints on traffic originating from ....

....the number of domains. ffl Inter domain routing protocols must automatically adapt to link cost changes and node link failures and repairs, including failures that partition domains [11] A straight forward approach to inter domain routing is domain level source routing with link state approach [6, 4]. In this approach, each router 2 maintains a domain level view of the internetwork, i.e. a graph with a vertex for every domain and an edge between every two neighbor domains. Policy and ToS information is attached to the vertices and the edges of the view. When a source node needs to reach a ....

[Article contains additional citation context not shown here]

D.D. Clark. Policy routing in Internet protocols. Request for Comment RFC-1102, Network Information Center, May 1989.

....represent stub networks. An internetwork is organized into domains 2 . A domain is a set of networks (possibly consisting of only one network) administered by the same agency. Domains are typically subject to policy constraints, which are administrative restrictions on inter domain traffic [7, 11, 8, 5]. The policy constraints of a domain U are of two types: transit policies, which specify how other domains can use the resources of U (e.g. 0.01 per packet, no traffic from domain V ) and source policies, which specify constraints on traffic originating from U (e.g. domains to avoid prefer, ....

.... routing protocol should automatically adapt to link cost changes and node link failures and repairs, including failures that partition domains [13] A Straight Forward Approach A straight forward approach to inter domain routing is domain level source routing with link state approach [7, 5]. In this approach, each router 3 maintains a domain level view of the internetwork, i.e. a graph with a vertex for every domain and an edge between every two neighbor domains. Policy and ToS information is attached to the vertices and the edges of the view. When a source node needs to reach a ....

[Article contains additional citation context not shown here]

D.D. Clark. Policy routing in Internet protocols. Request for Comment RFC-1102, Network Information Center, May 1989.

....Across all domains, an interdomain routing protocol is executed that provides routes between source and destination nodes in different domains. This protocol must satisfy various constraints: 1) It must satisfy policy constraints, which are administrative restrictions on the interdomain traffic [9], 13] 10] 5] Policy constraints are of two types: transit policies and source policies. The transit policies of a domain specify how other domains can use the resources of (e.g. 0.01 per packet, no traffic from domain ) The source policies of a domain specify constraints on traffic ....

.... routes as back doors ) 4) Interdomain routing protocols must automatically adapt to link cost changes, node link failures and repairs including failures that partition domains [15] A simple straightforward approach to interdomain routing is domain level source routing with link state approach [9], 5] In this approach, each router 3 maintains a domain level view of the internetwork, i.e. a graph with a vertex for every domain and an edge between every two neighbor domains. Policy and ToS information is attached to the vertices and the edges of the view. When a source node needs to ....

[Article contains additional citation context not shown here]

D. D. Clark, "Policy routing in Internet protocols," Request for Comment RFC-1102, Network Information Center, May 1989.

....Thus, views in our viewserver schemes will be more up to date. As we pointed out in [3] the only drawback of our protocol is that to obtain a source route for a VC, views are merged at (or prior to) the VC setup, thereby increasing the setup time. This drawback is not unique to our scheme [10, 18, 8, 13]. Reference [3] describes several ways, including cacheing and replication, to reduce the setup overhead and improve performance. ....

D.D. Clark. Policy routing in Internet protocols. Request for Comment RFC-1102, Network Information Center, May 1989.

....we focus on the design and evaluation of distributed hierarchy construction and maintenance algorithms for large systems. The explosive growth in the size of computer networks has necessitated the use of hierarchies to improve scaling. Examples include hierarchies for naming[1] and routing [2, 3, 4, 5, 6, 7, 8, 9] in the Internet. Many applications for hierarchies also arise in networks of embedded systems (see Section 5) Hierarchies of network entities or nodes are basically constructed by defining parent child relationships among the nodes such that each node has a parent except the root node(s) Each ....

....by manual configuration of potential parents at each agent. Such manual configuration poses a very high administrative burden. In addition, the hierarchy is less robust since it cannot adapt to the failure of all the configured potential parents of an agent. Many hierarchical routing techniques [2, 3, 4, 5, 6, 7, 8, 9] have been proposed in the literature. In these proposals, a computer network is partitioned into smaller regions based on administrative constraints. Hierarchies of regions are manually configured to associate hierarchical names or addresses to regions and to distribute this routing information ....

D. Clark. Policy routing in Internet Protocols. RFC-1102, May 1989.

.... server at colorado will talk to the server at polimi (and vice versa) This assumption significantly reduces the variable space thus simplifying the set of scenarios that we will cover, and it is also very reasonable since it reflects the structure of domains that characterizes the Internet [14]. The scenarios we are simulating at this time include only homogeneous event service topologies. In addition to the distributed topologies, we simulate also a reference centralized topology that we use as a baseline for our comparison. centralized in this case there will be one server for the ....

D. Clark. Policy Routing in Internet Protocols. Internet Requests For Comments (RFC) 1102, May 1989.

....the locations and interconnections among servers are an image of the underlying network topology. This assumption significantly reduces the parameter space in the simulation. Nonetheless, this is a reasonable assumption, since it reflects the structure of domains that characterize the Internet [9]. In addition to simulating the various multi server architectures, we simulate a single server, centralized architecture. The centralized architecture serves as a reference architecture that we use as a baseline for our comparisons; where the centralized architecture performs as well as or ....

D. Clark. Policy routing in internet protocols. Internet Requests For Comments (RFC) 1102, May 1989.

....trusted repositories. 2 Background An early routing policy system used in the NSFNET, the policy routing database (PRDB) provided a means of determining who was authorized to announce specific prefixes to the NSFNET backbone. The need for a policy database was recognized as far back as 1989 [6, 4]. By 1991 the database was in place [5] Authentication was accomplished by requiring confirmation and was a manually intensive process. This solved the problem for the NSFNET, but was oriented toward holding the routing policy of a single organization. The problem since has become more ....

D.D. Clark. Policy routing in Internet protocols. Technical Report RFC 1102, Internet Engineering Task Force, 1989. ftp://ftp.isi.edu/in-notes/rfc1102.txt.

....are cited as uses for source routing. These topics, however, were not pursued in detail. More recently, Perlman, in her thesis [81] explored in detail the use of source routes to discover and route around misbehaving routers. Some recent papers consider the use of source routes for policy reasons [11, 35, 94, 101, 21]. Policy routing can broadly be defined as the capability to choose among multiple paths from source to destination. This capability is usually exercised by the source. Common reasons for choosing among multiple paths are 1) some paths are administratively restricted for a given communications, 2) ....

D. Clark. Policy routing in Internet Protocols. Request For Comments 1102, University of Southern California Information Sciences Institute, May 1989.

....Thus, views in our viewserver schemes will be more up to date. As we pointed out in [3] the only drawback of our protocol is that to obtain a source route for a VC, views are merged at (or prior to) the VC setup, thereby increasing the setup time. This drawback is not unique to our scheme [8, 16, 7, 11]. Reference [3] describes several ways, including cacheing and replication, to reduce the setup overhead and improve performance. ....

D.D. Clark. Policy routing in Internet protocols. Request for Comment RFC-1102, Network Information Center, May 1989.

....all domains, an inter domain routing protocol is executed that provides routes between source and destination nodes in different domains. This protocol must satisfy various constraints: 1) It must satisfy policy constraints, which are administrative restrictions on the inter domain traffic [9, 13, 10, 5]. Policy constraints are of two types: transit policies and source policies. The transit policies of a domain A specify how other domains can use the resources of A (e.g. 0.01 per packet, no traffic from domain B) The source policies of a domain A specify constraints on traffic originating ....

.... as back doors ) 4) Inter domain routing protocols must automatically adapt to link cost changes, node link failures and repairs including failures that partition domains [15] A simple straightforward approach to inter domain routing is domain level source routing with link state approach [9, 5]. In this approach, each router 3 maintains a domain level view of the internetwork, i.e. a graph with a vertex for every domain and an edge between every two neighbor domains. Policy and ToS information is attached to the vertices and the edges of the view. When a source node needs to reach a ....

[Article contains additional citation context not shown here]

D.D. Clark. Policy routing in internet protocols. Request for Comment RFC-1102, Network Information Center, May 1989.

....actual internetworks. We also do not model link characteristics (e.g. bandwidth) such information can be easily included as an overlay to the basic topological structure, as needed for studying particular problems. Today s Internet can be viewed as a collection of interconnected routing domains [19], which are groups of nodes that are under a common administration and share routing information. A primary characteristic of these domains is routing locality: the path between any two nodes in a domain stays entirely within the domain. Each routing 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 ....

David Clark. Policy routing in internet protocols. Internet Request for Comments 1102, May 1989.

....1 Star n Gamma 1 2 n Mesh 2(n Gamma p n) 2( p n Gamma 1) 1 Figure 4: Properties of regular graphs nodes exhibit locality characteristics corresponding to those observed in the Internet. 4. 1 Domain Structure Today s Internet can be viewed as a collection of interconnected routing domains [5], which are groups of nodes that are under a common administration and share routing information. A primary characteristic of these domains is routing locality: the path between any two nodes in a domain stays entirely within the domain. Each routing domain in the Internet can be classified as ....

David Clark. Policy routing in internet protocols. Internet Request for Comments 1102, May 1989.

.... strong consistency or durability, but rather high availability of data: Stale data can be temporarily tolerated as long as all copies of data eventually reach consistency after a short time [19] e.g. DNS servers do not reach consistency until entry timeouts expire [39] Soft state [13], which can be regenerated at the expense of additional computation or file I O, is exploited to improve performance; data is not durable. Approximate answers (based on stale data or incomplete soft state) delivered quickly may be more valuable than exact answers delivered slowly. We refer to ....

D.Clark. Policy Routing in Internet Protocols. Internet Request for Comments 1102, May 1989,

....about how an efficient pricing mechanism might work. Obviously, our suggestions must be viewed as extremely tentative. However, we hope that an explicit proposal, such as we describe below, can at least serve as a starting point for further discussion. We wholeheartedly adopt the viewpoint of Clark (1989) who says It is useful to think of the interconnected [networks] as a marketplace, in which various services are offered and users select among these services to obtain packet transport. We take this point of view further and examine what kind of pricing policy makes sense in the context of a ....

Clark, D. (1989). Policy routing in internet protocols. Tech. rep. RFC1102, M.I.T. Laboratory for Computer Science.

....process. On the other hand, at a number of points in the design process, it is more important to maintain high availability and low latency access to information than to ensure strong consistency or durability of the data. Approximate answers, based on stale information[11] or incomplete soft state[12], that are delivered quickly may be more valuable than precise data delivered more slowly or requiring some form of transitive closure across the entire design state. The semantics resulting from these requirements have been referred to as BASE[10] Basically Available, Soft State, Eventual ....

D. Clark, "Policy Routing in Internet protocols," Internet Request for Comments No.1102, May 1989.

....game theory [3, 4] Existing networks have avoided dealing with the above mentioned issues. The Internet[5, 6] for example, uses a routing protocol that is based on topological considerations alone without regard to other optimization criteria. Recently, policy based routing has been deliberated[7], but this approach does not accommodate general dynamics or individual user characteristics. This paper addresses the most basic networking problem the routing problem from a game theoretical standpoint, contributing to the understanding of the dynamics of modern networks. Most previous work ....

D. Clark, "Policy routing in internet protocols," Tech. Rep. RFC 1102, DDN Network Information Center, Menlo Park, California, May 1989.

....provider is of particular interest in this paper. For this purpose, source routing is required to enforce the choice. IPv6 [DEF 95] for instance, provides the necessary support, which is also required for QoS routing. Source routing for provider selection is different from policy routing [Cla89] which enables network providers to route traffic based on policies. Nevertheless, many issues are the same for both approaches. The implementation of source routing for service provider selection is not further discussed in this paper. 2 Social Carrier Recommendation The basic idea of SCR is ....

David Clark. Policy routing in internet protocols. RFC 1102, May 1989.

....and perspective and therefore must make its own evaluation of legal and preferred routes. Efforts are now underway to develop a new generation of routing protocol that will allow each AD to independently express and enforce policies regarding the flow of packets to, from, and through its resources[4]. 4 The purpose of this paper is to articulate the requirements for such policy based routing. Two critical assumptions will shape the type of routing mechanism that is devised: ffl The topological organization of ADs, and ffl The type and variability of policies expressed by ADs. We make use of ....

....AD s own count, the count of some upstream or downstream AD) ffl Bound on charges (e.g. to limit the amount that a stub AD is willing to spend, or the amount that a transit AD is willing to carry. The enforcement of these policies may be carried out during route synthesis or route selection[4] 6.3 Example Policy statements The following policy statements were collected in the fall of 1988 through interviews with representatives of the federal agencies most involved in supporting internetworking. Once again we emphasize that these are not official policy statements. They are presented ....

[Article contains additional citation context not shown here]

D. Clark, Policy Routing in Internet Protocols, Network Information Center, RFC 1102, May 1989.

....thinking about how such a pricing mechanism might work. Obviously, our suggestions must be viewed as extremely tentative. However, we hope that an explicit proposal, such as we describe below, can at least serve as a starting point for further discussion. We wholeheartedly adopt the viewpoint of Clark (1989) who says It is useful to think of the interconnected [networks] as a marketplace, in which various services are offered and users select among these services to obtain packet transport. We take this point of view further to examine what kind of pricing policy makes sense in the context of a ....

Clark, D. (1989). Policy routing in internet protocols. Tech. rep. RFC1102, M.I.T. Laboratory for Computer Science.

.... server at colorado will talk to the server at polimi (and vice versa) This assumption significantly reduces the variable space thus simplifying the set of scenarios that we will cover, and it is also very reasonable since it reflects the structure of domains that characterizes the Internet [14]. The scenarios we are simulating at this time include only homogeneous event service topologies. In addition to the distributed topologies, we simulate also a reference centralized topology that we use as a baseline for our comparison. centralized in this case there will be one server for the ....

D. Clark. Policy Routing in Internet Protocols. Internet Requests For Comments (RFC) 1102, May 1989.

No context found.

David Clark. Policy Routing in Internet Protocols. Internet Engineering Task Force, May 1989. RFC 1102.

No context found.

CLARK, D. Policy Routing in Internet Protocols. Internet Engineering Task Force, May 1989. RFC 1102.

No context found.

D. Clark. Policy routing in internet protocols. RFC 1102, http://www.faqs.org/ftp/rfc/rfc1102. txt, 1989.

No context found.

David Clark. Policy routing in Internet protocols, May 1989. RFC 1102, SRI Network Information Center.

No context found.

D. Clark, "Policy routing in internet protocols," Tech. Rep. RFC 1102, DDN Network Information Center, Menlo Park, California, May 1989.

No context found.

CLARK, D. Policy routing in internet protocols. RFC 1102, http://www.faqs.org/ftp/rfc/rfc1102. txt, 1989.

No context found.

CLARK, D. Policy routing in internet protocols. RFC 1102, http://www.faqs.org/ftp/rfc/rfc1102. txt, 1989.

No context found.

RFC 1102, D. Clark, "Policy Routing in Internet Protocols," Network working group, May 1989, http://www.ietf.org/rfc/rfc1102.txt.

No context found.

D. Clark, Policy Routing in Internet Protocols, Network Information Center, RFC 1102, May 1989.

No context found.

Clark, D., "Policy Routing in Internet Protocols", RFC 1102, M.I.T. Laboratory for Computer Science, May 1989.

No context found.

D. D. Clark. Policy routing in Internet protocols. RFC 1102, IETF, May 1989.

No context found.

CLARK, D. Policy Routing in Internet Protocols. Internet Engineering Task Force, May 1989. RFC 1102.

No context found.

D.D. Clark. Policy routing in internet protocols. Technical Report RFC 1102, Internet Engineering Task Force, 1989. ftp://ds.internic.net/rfc/rfc1102.txt.

No context found.

Clark, D., "Policy Routing in Internet Protocols", RFC 1102, May 1989.

No context found.

Clark, D., "Policy Routing in Internet Protocols", RFC 1102, May 1989.

No context found.

Clark, D., "Policy Routing in Internet Protocols", RFC 1102, M.I.T., May 1989. Security Considerations Security issues are not discussed in this memo.

No context found.

D. D. Clark, "Policy Routing in Internet Protocols," M.I.T. Laboratory for Computer Science, May 1989

No context found.

Clark, D. (1989). Policy routing in internet protocols. Tech. rep. RFC1102, M.I.T. Laboratory for Computer Science.

No context found.

D. D. Clark, "Policy Routing in Internet Protocols," M.I.T. Laboratory for Computer Science, May 1989

No context found.

D. Clark, Policy Routing in Internet Protocols, Journal of Internetworking: Research and Experience, October 1990.

No context found.

D. Clark, Policy Routing in Internet Protocols, Journal of Internetworking: Research and Experience, October 1990.

No context found.

D.Clark. Policy Routing in Internet Protocols. Internet Request for Comments 1102, May 1989,

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC