Patent Grant
10757020
It is unlikely that the designers of the early network that is now referred to as the “Internet” expected it to become as large as it has become. The fact that the global Internet Protocol (IP) address space for 32-bit addresses has been fully allocated is evidence of this. As the Internet grows, new problems will arise and some current problems are getting worse. For example, while network speeds and bandwidth are increases, so are causes of network latency.
The Internet Engineering Task Force (IETF) has taken steps at various times in the past and are presently taking steps to address a number of problems resulting from the Internet's growth. Problems addressed by the IETF are described in a number of “Request for Comments” (RFC) documents published the IETF. Documents referenced herein include: “Request for Comments” (RFC) document RFC 791 edited by J. Postel, titled “Internet Protocol, DARPA Internet Protocol Specification”, published by the IETF in September, 1981;
“Request for Comments” (RFC) document RFC 201519 by V. Fuller, et al, titled “Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy”, published by the Internet Engineering Task Force (IETF), in June, 1999;
“Request for Comments” (RFC) document RFC 2410 by S. Deering, et al, titled “Internet Protocol, Version 206, (IPv6) Specification”, published by the IETF in December, 1998;
“Request for Comments” (RFC) document RFC 3513 by R. Hinden, et al, titled “Internet Protocol Version 6 (IPv6) Addressing Architecture”, published by the IETF in April, 2003; and
“Request for Comments” (RFC) document RFC 2374 by R. Hinden, et al, titled “Aggregatable Global Unicast Address Format”, published by the IETF in July, 1998.
The authors of RFC 201519 in dealing with a number of issues state that their proposal”.
RFC 791 states, “The internet protocol implements two basic functions: addressing and fragmentation”. RFC 791 goes on to state, “A distinction is made between names, addresses, and routes. A name indicates what we seek. An address indicates where it is. A route indicates how to get there. The internet protocol deals primarily with addresses. It is the task of higher level (i.e., host-to-host or application) protocols to make the mapping from names to addresses. The internet module maps internet addresses to local net addresses. It is the task of lower level (i.e., local net or gateways) procedures to make the mapping from local net addresses to routes”.
Further new protocols and platforms for building new protocols, such as OpenFlow of the Open Network Foundation (ONF), have been introduced, and will continue to be introduced. Such protocols and platforms are within the scope of the subject matter of the present disclosure. The OpenFlow protocol is specified in “OpenFlow Switch Specification”, by Pfaff, B, et al, and published by the ONF in Feb. 29, 2011.
In order to address a number of current and future problems facing the Internet, the subject matter described herein challenges the distinctions asserted in RFC 791 and establishes new relationships between and among names, addresses, and routes. The description herein further demonstrates that current internet addresses do not indicate where a node or network interface component (NIC) of a node is. They provide another global identifier space for identifying nodes and their network interfaces. This global identifier space to some extent is duplicative of the domain name space, which is also a global identifier space for identifying nodes and network interfaces. This duplication of roles is unnecessary as described below.
Accordingly, there exists a need for methods, systems, and computer program products for associating a name with a network path.
The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not an extensive overview of the disclosure and it does not identify key/critical elements of the invention or delineate the scope of the invention. Its sole purpose is to present some concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.
In one embodiment, a non-transitory computer-readable media is provided storing computer instructions that, when executed by one or more processors of a first node in a network, cause the first node to: receive an Internet Protocol (IP) packet that includes a first identifier and further includes an outside-scope second identifier that, for the first node, identifies a first region that does not include the first node and that is communicatively coupled to the first node via a second node; select, based on the outside-scope second identifier and based on at least one of a policy, a metric, or a routing table, an outgoing network interface included in at least one path segment of a plurality of path segments that communicatively couple the first node and at least one other node communicatively coupled to the first region, the plurality of path segments including at least one multi-hop path segment; and forward, via the outgoing network interface and to the second node, data received in the IP packet.
In still another embodiment, an apparatus is provided, comprising: a first node including at least one non-transitory memory configured to store instructions, and one or more processors in communication with the at least one non-transitory memory, wherein the one or more processors is configured to execute the instructions to cause the first node to: receive an Internet Protocol (IP) packet that includes a first identifier and further includes an outside-scope second identifier that, for the first node, identifies a first region that does not include the first node and that is communicatively coupled to the first node via a second node; select, based on the outside-scope second identifier and based on at least one of a policy, a metric, or a routing table, an outgoing network interface included in at least one path segment of a plurality of path segments that communicatively couple the first node and at least one other node communicatively coupled to the first region, the plurality of path segments including at least one multi-hop path segment; and forward, via the outgoing network interface and to the second node, data received in the IP packet.
In yet still another embodiment, a method is provided, comprising: at a first node in a network: receiving an Internet Protocol (IP) packet that includes a first identifier and further includes an outside-scope second identifier that, for the first node, identifies a first region that does not include the first node and that is communicatively coupled to the first node via a second node; selecting, based on the outside-scope second identifier and based on at least one of a policy, a metric, or a routing table, an outgoing network interface included in at least one path segment of a plurality of path segments that communicatively couple the first node and at least one other node communicatively coupled to the first region, the plurality of path segments including at least one multi-hop path segment; and forwarding, via the outgoing network interface, data received in the IP packet.
In even still another embodiment, a first node is provided, comprising: means for receiving an Internet Protocol (IP) packet that includes a first identifier and further includes an outside-scope second identifier that, for the first node, identifies a first region that does not include the first node and that is communicatively coupled to the first node via a second node; means for selecting, based on the outside-scope second identifier and based on at least one of a policy, a metric, or a routing table, an outgoing network interface included in at least one path segment of a plurality of path segments that communicatively couple the first node and at least one other node communicatively coupled to the first region, the plurality of path segments including at least one multi-hop path segment; and means for forwarding, via the outgoing network interface and to the second node, data received in the IP packet.
Methods and systems are described for associating a name with a network path. In one aspect, the method includes receiving a first message, from a first node by a second node via a first network path in a network, identifying a first symbolic identifier of the first node, wherein the first network path includes a first hop included in communicatively coupling the first node and the second node. The method further includes identifying second path information identifying a second hop in a second network path included in communicatively coupling the second node and a third node. The method still further includes sending a second message, identifying the first symbolic identifier and the first hop, to the third node via the second hop to associate the first symbolic identifier with a third network path that includes a node included in at least one of the first hop and the second hop. Performing at least one the preceding actions comprising the method includes execution of an instruction by a processor.
Also, a system for associating a name with a network path is described that includes at least one processor; and logic encoded in at least one data storage media for execution by the at least one processor that when executed is operable for and/or is otherwise included in receiving a first message, from a first node by a second node via a first network path in a network, identifying a first symbolic identifier of the first node, wherein the first network path includes a first hop included in communicatively coupling the first node and the second node; identifying second path information identifying a second hop in a second network path included in communicatively coupling the second node and a third node; and sending a second message, identifying the first symbolic identifier and the first hop, to the third node via the second hop to associate the first symbolic identifier with a third network path that includes a node included in at least one of the first hop and the second hop.
Further, a system for associating a name with a network path is described. The system includes a processor that executes an instruction included in at least one of a resolver component, a topology space component, and a topology relay component during operation of the system. During operation of the system the resolver component is operable for and/or is otherwise included in receiving a first message, from a first node by a second node via a first network path in a network, identifying a first symbolic identifier of the first node, wherein the first network path includes a first hop included in communicatively coupling the first node and the second node; the topology space component is operable for and/or is otherwise included in identifying second path information identifying a second hop in a second network path included in communicatively coupling the second node and a third node; and the topology relay component is operable for and/or is otherwise included in sending a second message, identifying the first symbolic identifier and the first hop, to the third node via the second hop to associate the first symbolic identifier with a third network path that includes a node included in at least one of the first hop and the second hop.
Methods and systems are described for associating a name with a network path. In one aspect, the method includes detecting, by a second node in a network, a first node in first hop included in communicatively coupling the second node and the first node. The method further includes determining a first hop identifier for the first hop. The method still further includes sending, by the second node, the first hop identifier to a topology service to include a representation of the first node in a first location in a topological space, wherein the first location is identified relative to the second node based on the first hop identifier. Performing at least one the preceding actions comprising the method includes execution of an instruction by a processor.
Also, a system for associating a name with a network path is described that includes at least one processor; and logic encoded in at least one data storage media for execution by the at least one processor that when executed is operable for and/or is otherwise included in detecting, by a second node in a network, a first node in first hop included in communicatively coupling the second node and the first node; determining a first hop identifier for the first hop; and sending, by the second node, the first hop identifier to a topology service to include a representation of the first node in a first location in a topological space, wherein the first location is identified relative to the second node based on the first hop identifier.
Further, a system for associating a name with a network path is described. The system includes a processor that executes an instruction included in at least one of a topology monitor component, a topology space component, and a topology communication component during operation of the system. During operation of the system the topology monitor component is operable for and/or is otherwise included in detecting, by a second node in a network, a first node in first hop included in communicatively coupling the second node and the first node; the topology space component is operable for and/or is otherwise included in determining a first hop identifier for the first hop; and the topology communication component is operable for and/or is otherwise included in sending, by the second node, the first hop identifier to a topology service to include a representation of the first node in a first location in a topological space, wherein the first location is identified relative to the second node based on the first hop identifier.
Objects and advantages of the present invention will become apparent to those skilled in the art upon reading this description in conjunction with the accompanying drawings, and in which:
One or more aspects of the disclosure are described with reference to the drawings, wherein like reference numerals are generally utilized to refer to like elements throughout, and wherein the various structures are not necessarily drawn to scale. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more aspects of the disclosure. It may be evident, however, to one skilled in the art, that one or more aspects of the disclosure may be practiced with a lesser degree of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing one or more aspects of the disclosure. It is to be understood that other embodiments and/or aspects may be utilized and structural and functional modifications may be made without departing from the scope of the subject matter disclosed herein.
An “execution environment”, as used herein, is an arrangement of hardware and, in some aspects, software that may be further modified, transformed, and/or otherwise configured to include and/or otherwise host an arrangement of components to perform a method of the subject matter described herein. An execution environment includes a processor to execute an instruction included in at least one component of such an arrangement. An execution environment includes and/or is otherwise provided by one or more devices. The execution environment is said to be the execution environment “of” the device and/or devices. Exemplary devices included in and/or otherwise providing suitable execution environments that may be adapted, programmed, and/or otherwise modified according to the subject matter include a workstation, a desktop computer, a laptop or notebook computer, a server, a handheld computer, a mobile telephone or other portable telecommunication device, a media playing device, a gaming system, a tablet computer, a portable electronic device, a handheld electronic device, a multiprocessor device, a distributed system, a consumer electronic device, a router, a network server, or any other type and/or form of computing, telecommunications, network, and/or media device that is suitable to perform the subject matter described herein. Those skilled in the art will understand that the components illustrated in
As used herein a “processor” is an instruction execution machine, apparatus, or device. A processor may include one or more electrical, optical, and/or mechanical components that operate in interpreting and executing program instructions. Exemplary processors include one or more microprocessors, digital signal processors (DSPs), graphics processing units, application-specific integrated circuits (ASICs), optical or photonic processors, and/or field programmable gate arrays (FPGAs).
The terms “network node” and “node” in this document both refer to a device having a network interface component for operatively coupling the device to a network. Further, the terms “device” and “node” used herein refer to one or more devices and nodes, respectively, providing and/or otherwise included in an execution environment unless clearly indicated otherwise.
A computer program may include one or more software components. As used herein, the term “software component” refers to any data representation that may be and/or may be translated into a set of machine code instructions and may optionally include associated data. Software component representations other than machine code include object code, byte code, and source code. Object code includes a set of instructions and/or data elements that either are prepared to link prior to loading or are loaded into an execution environment. When in an execution environment, object code may include references resolved by a linker and/or may include one or more unresolved references. The context in which this term is used will make clear the state of the object code when it is relevant. This definition can include machine code and virtual machine code, such as Java™ byte code. A software component may include one or more components. As used herein, the terms “application”, and “service” may be realized in one or more software components and/or in one or more hardware components.
Software components typically include instructions executed by a processor in a computing context referred to as a “process”. A process may include one or more “threads”. A “thread” includes a sequence of instructions executed by a processor in a computing sub-context of a process. The terms “thread” and “process” may be used interchangeably herein when a process includes only one thread.
As used herein, the term “network protocol” refers to a set of rules, conventions, and/or schemas that govern how nodes exchange information over a network. The set may define, for example, a convention and/or a data structure. The term “network path” as used herein refers to a sequence of nodes in a network that are communicatively coupled to transmit data in one or more data units of a network protocol between a pair of nodes in the network.
A “data unit”, as the term is used herein, is an entity specified according to a network protocol to transmit data between a pair of nodes in a network path to send the data from a source node to a destination node that includes an identified protocol endpoint of the network protocol. A network protocol explicitly and/or implicitly specifies and/or otherwise identifies a schema that defines one or more of a rule for a format for a valid data unit and a vocabulary for content of a valid data unit. One example of a data unit is an Internet Protocol (IP) packet. The Internet Protocol defines rules for formatting an IP packet that defines a header to identify a destination address that identifies a destination node and a payload portion to include a representation of data to be delivered to the identified destination node. Various address types are specified defining a vocabulary for one or more address portions of an IP data unit. The terms “data unit”, “frame”, “data packet”, and “packet” are used interchangeably herein. One or more data units of a first network protocol may transmit a “message” of a second network protocol. For example, one or more data units of the IP protocol may include a TCP message. In another example, one or more TCP data units may transmit a HTTP message. A message may be empty.
How data is packaged in one more data units for a network protocol may vary as the data traverses a network path from a source node to a destination node. Data may be transmitted in a single data unit between two consecutive nodes in a network path. Additionally, data may be exchanged between a pair of consecutive nodes in several data units each including a portion of the data. Data received in a single data unit by a node in a network path may be split into portions included in several respective data units to transmit to a next node in the network path. Portions of data received in several data units may be combined into a single data unit to transmit by a node in a network path. For purposes of describing the subject matter, a data unit in which data is received by a node is referred to as a different data unit than a data unit in which the data is forwarded by the node.
A “protocol address”, as the term is used herein, for a network protocol is an identifier of a protocol endpoint that may be represented in a data unit of the network protocol. For example, 192.168.1.1 is an IP protocol address represented in a human readable format that may be represented in an address portion of an IP header to identify a source and/or a destination IP protocol endpoint. A protocol address differs from a symbolic identifier, defined below, in that a symbolic identifier, with respect to a network protocol, maps to a protocol address. Thus, “www.mynode.com” may be a symbolic identifier for a node in a network when mapped to the protocol address 192.168.1.1. An identifier may be both a symbolic identifier and a protocol address depending on its role with respect to its use for a particular network protocol.
Since a protocol endpoint is included in a node and is accessible via a network via a network interface, a protocol address identifies a node and identifies a network interface of the node. A network interface may include one or more NICs operatively coupled to a network.
A node in a pair of nodes in a network path at one end of the sequence of nodes in the network path and/or the other end is referred to herein as a “path end node”. Note that a node may have two NICs with one NIC at each end of a network path. A network path may be included as a portion of another network path that communicatively couples a same pair of nodes. Data may be transmitted via the sequence of nodes in a network path between path end nodes communicatively coupled via the network path. Data may be transmitted in one or both directions depending on an ordering of the nodes in the sequence.
The term “hop” as used herein refers to a pair of consecutive nodes in a network path to transmit, via a network protocol, data sent from a source node to a destination node. A “hop path” is thus a sequence of hops in a network that respectively include a sequence of pairs of consecutive nodes included in transmitting data from a first path end node of the network path to a second path end node of the network path.
The term “path-based protocol address” as used herein refers to a protocol address for a network protocol that includes one or more path segment identifiers that identify one or more respective portions of a network path identified by the path-based protocol address. A “node-based protocol address” is a path-based protocol address that includes a plurality of node identifiers that identify a sequence of nodes in a network path. A “network-interface-based protocol address” is a path-based protocol address that includes a plurality of network interface identifiers that identify a sequence of network interfaces in a network path. A “NIC-based protocol address” is a type of network-interface-based protocol address that includes a plurality of identifiers that identify a sequence of network interface components. A “hop-based protocol address” is a type path-based protocol address since a hop is a type of network path.
Given the above definitions, note that the terms “network path” and “hop” may be defined in terms of network interfaces. A “network path” and a “hop path” include a sequence of network interfaces in a network that are included in transmitting data between a pair of path end nodes in the network. A “hop” refers to at least part of a network path that includes a pair of consecutive network interfaces in a sequence of network interfaces in a network path. A “network path” is thus a sequence of hops in a network that respectively includes a sequence of pairs of consecutive network interfaces included in transmitting data from a first path end node of the network path to a second path end node of the network path.
The term “network topology” or “topology”, for short, as used herein refers to a representation of protocol endpoints and/or nodes in a network, and representations of hops representing communicative couplings between and/or among the protocol endpoints and/or nodes in the network. A network may have different network topologies with respect to different network protocols. A network topology may represent physical communicative couplings between nodes in the network. A network topology may represent logical couplings between protocol endpoints and/or nodes of a particular network protocol or a particular type of network protocol.
The domain name system (DNS) of the Internet operates based on an application layer protocol defined by the DNS. The nodes in the DNS are communicatively coupled via the DNS protocol and may be represented by a logical network topology. A DNS system includes nodes connected via the DNS protocol. The DNS system has a network topology defined by nodes that include protocol endpoints of the DNS protocol. In still another example, a token-ring network has a circular topology at the link layer, but may have a star topology at the physical layer.
As used herein, an “entity-specific address space” refers to an address space defined for a specific entity where the addresses in the address space operate as identifiers in the context of the entity. An address from an entity-specific address space is referred to herein as an “entity-specific address”. An address is “entity-specific” in that what it identifies is based on the entity to which it is specific. Another address having the same form and content may identify a different entity when in an address space specific to another entity. Addresses in an entity-specific address space operate as identifiers in the context of an entity to which they are “specific” as defined by the specific association of the address space and the entity. Without knowledge of the entity to which an entity-specific address space is specific, what an address in the entity-specific address space identifies is indeterminate. The terms “entity-specific address” and “entity-specific identifier” are used interchangeably herein. An entity-specific address may identify an entity included in the entity to which the address is specific or may identify an entity external to the entity to which the address is specific. The fact that an address is entity-specific does not define a scope for the address.
A portion of a network is a type of entity. A type of entity-specific address space described herein is a scope-specific address space. As used herein, a “scope-specific address space”, specific to a particular region of a network, is an address space defined for the particular network region, where an address in the scope-specific protocol address operates as identifier, according to a network protocol, of a protocol endpoint in a node outside of the particular region when processed in the context of a node in the particular region. The region is indicated by the span of an indicated scope. The terms “region” and “zone” are used interchangeably herein. An address from a scope-specific address space is referred to herein as a “scope-specific protocol address”. An address is “scope-specific” in that what protocol endpoint it identifies depends on the region to which it is specific. Another address having the exact same form and content may identify a different protocol endpoint when in an address space that is specific to another region. A protocol address in a scope-specific address space serves as an identifier in the context of a node in a region to which the scope-specific address space is “specific” as defined by an association of the address space and the region indicated by the scope. Without knowledge of the particular region to which a scope-specific address space is specific, what a scope-specific protocol address in the scope-specific address space identifies is indeterminate. The terms “scope-specific protocol address” and “scope-specific protocol identifier” are used interchangeably herein. Types of scope-specific address spaces indicating exemplary spans include site-specific, LAN-specific, subnet-specific, city-specific, business-specific, and node-specific.
For a network protocol, an address in a scope-specific address space serves as an identifier of a protocol endpoint in a node. Data may be received via the protocol endpoint from a network via one or more network interfaces that operatively couple the node to the network. Data may be sent via the protocol endpoint to transmit over the network via the one or more network interfaces in the node. Since a protocol endpoint of a network protocol is included in a node and is accessible via a network via a network interface, a protocol address identifying the protocol endpoint also identifies the node and identifies a network interface of the node.
As used herein, a “node-specific address space” is a scope-specific address space defined for a specific node in a network, where the addresses in the node-specific address space operate as identifiers of nodes and/or network interfaces in the network when processed in the context of the specific node. An address from a node-specific address space is referred to herein as a “node-specific address”. An address is “node-specific” in that what it identifies depends on the node to which is defined as specific. Another address having the exact same form and content may identify a different node when in an address space specific to another node. Addresses in a node-specific address space operate as identifiers in the context of a node to which they are “specific” as defined by the specific association of the address space and the node. Without knowledge of the node to which a node-specific address space is specific, addresses in the node-specific address space are indeterminate. The terms “node-specific address” and “node-specific identifier” are used interchangeably herein. A node-specific address space is a type of scope-specific address space.
The term “node” is defined above. Note that an identifier of a network interface in a network also identifies a node that includes the network interface. Thus, a network interface-specific address is also a node-specific address. Network interfaces in a node may have their own respective network interface-specific address spaces that are also node-specific. The network interface-specific address spaces may be combined to form a node-specific address space and/or may be managed as separate address spaces. The adjectives “node-specific” and “network interface-specific” may be used interchangeably.
A scope-specific identifier differs from a scoped address as described in “Request for Comments” (RFC) document RFC 4007 by S. Deering, et al, titled “IPv6 Scoped Address Architecture”, published by the IETF in December, 2006 and further described in application Ser. No. 11/962,285, by the present inventor, filed on 2007 Dec. 21, entitled “Methods and Systems for Sending Information to a zone Included in an internet Network”. A scoped address space is shared by nodes in a given scope. While a link-local scoped address is specific to a particular node, a link-local scoped address simply identifies a network interface component local to the particular node. A loop-back internet address is specific to a node as well. Neither link-local scoped addresses nor loop-back addresses identify one node to another. As such, neither serves as a node-specific identifier as defined above.
A “scoped address” is described by RFC 3513 and RFC 4007 as an identifier that, in a particular region of a network, serves as a protocol address of a network interface and/or a node in the particular region. The extent of the particular region is referred to as the scope of the region and thus the scope within which the identifier serves as a protocol address. A particular region included within a scope is indicated by its span. A scoped address is a valid protocol address only within a particular region as indicated by the address's indicated scope. Examples of scope indicators include node-scope where identifiers are valid only to a single node in the indicated span, LAN-scope where identifiers are valid for nodes in the span of a particular LAN, and subnet-scope where identifiers are valid only for nodes in a particular subnet. RFC 3513 currently defines support for link-local scope, site-local scope, and global scope. A data unit transmitted with a scoped address should not be delivered to node that does not have a network interface in the span indicated by the scope.
“Path information” is any information that identifies a network path and/or a hop path for data transmitted via one a specified network protocols. Path information may be identified by identifying network interfaces, NICs, nodes, and/or hops included in a network path. “Address information” is any information that identifies a protocol address that, for a network protocol, identifies a protocol endpoint. Address information may identify a unicast protocol address for a network protocol. In identifying a protocol endpoint, a protocol address identifies a node and a network interface.
Those skilled in the art will understand upon reading the descriptions herein that the subject matter disclosed herein is not restricted to the network protocols described and/or their corresponding OSI layers. For ease of illustration, the subject matter is described in terms of protocols that correspond to OSI layer three, also referred to as network layer protocols, in general. Particular descriptions are based on versions of the Internet Protocol (IP). Address information may identify one or more protocol addresses. Exemplary protocol addresses include IP addresses, IPX addresses, DECNet addresses, VINES Internet Protocol addresses, and Datagram Delivery Protocol (DDP) addresses, HTTP URLS, TCP port and IP address pairs, and the like.
The term “path-based address” is defined above. A “node-based address” is a path-based address where some or all of the address includes node identifiers that identify a sequence of nodes in a network path. A “network-interface-based address” is a path-based address where some or all of the address includes identifiers of network interfaces in a sequence in a network path. A “NIC-based address” is a type of network-interface-based address that identifies a sequence of network interface components. A “hop-based address” is a path-based address where some or all of the address identifies one or more hops in a network path. The protocol address types defined are not mutually exclusive.
The term “metric space”, as used herein, refers to a set, as defined in mathematics, where a distance between elements of the set is defined according to a metric. Metric spaces defined in Euclidean geometry are well-known examples. Those skilled in the art of metric spaces, such as Euclidian spaces, will appreciate that an one-to-one mapping may be determined and/or otherwise identified for mapping addresses from a first coordinate space having a first origin for a metric space to addresses from a second coordinate space having a second origin in the metric space. Given a mapping rule between a first scope-specific address space and a second scope-specific address space and a mapping between the second scope-specific address space and a third scope-specific address space based on a third coordinate space identifying a third origin in the metric space, a mapping from the first coordinate space to the third coordinate space may be determined. A mapping between coordinate spaces for a metric space may be included a coordinate shift and/or a rotation, for example. The mapping may be pre-specified and accessible to the nodes in one or both address spaces. Mapping between locations in a number of different metric spaces is well known in mathematics. For example, a top half of the surface of sphere may be mapped to a plane. Some will further appreciate that some metric spaces may be mapped to other metric spaces. Some of these mappings are one-to-one and/or onto.
An “execution environment”, as used herein, is an arrangement of hardware and, in some aspects, software that may be further modified, transformed, and/or otherwise configured to include and/or otherwise host an arrangement of components to perform a method of the subject matter described herein. An execution environment includes a processor to execute an instruction included in at least one component of such an arrangement. An execution environment includes and/or is otherwise provided by one or more devices. The execution environment is said to be the execution environment “of” the device and/or devices. Exemplary devices included in and/or otherwise providing suitable execution environments that may be adapted, programmed, and/or otherwise modified according to the subject matter include a workstation, a desktop computer, a laptop or notebook computer, a server, a handheld computer, a mobile telephone or other portable telecommunication device, a media playing device, a gaming system, a tablet computer, a portable electronic device, a handheld electronic device, a multiprocessor device, a distributed system, a consumer electronic device, a router, a network server, or any other type and/or form of computing, telecommunications, network, and/or media device that is suitable to perform the subject matter described herein. Those skilled in the art will understand that the components illustrated in
As used herein a “processor” is an instruction execution machine, apparatus, or device. A processor may include one or more electrical, optical, and/or mechanical components that operate in interpreting and executing program instructions. Exemplary processors include one or more microprocessors, digital signal processors (DSPs), graphics processing units, application-specific integrated circuits (ASICs), optical or photonic processors, and/or field programmable gate arrays (FPGAs).
The terms “network node” and “node” in this document both refer to a device having a network interface component for operatively coupling the device to a network. Further, the terms “device” and “node” used herein refer to one or more devices and nodes, respectively, providing and/or otherwise included in an execution environment unless clearly indicated otherwise.
A computer program may include one or more software components. As used herein, the term “software component” refers to any data representation that may be and/or may be translated into a set of machine code instructions and may optionally include associated data. Software component representations other than machine code include object code, byte code, and source code. Object code includes a set of instructions and/or data elements that either are prepared to link prior to loading or are loaded into an execution environment. When in an execution environment, object code may include references resolved by a linker and/or may include one or more unresolved references. The context in which this term is used will make clear the state of the object code when it is relevant. This definition can include machine code and virtual machine code, such as Java™ byte code. A software component may include one or more components. As used herein, the terms “application”, and “service” may be realized in one or more software components and/or in one or more hardware components.
Software components typically include instructions executed by a processor in a computing context referred to as a “process”. A process may include one or more “threads”. A “thread” includes a sequence of instructions executed by a processor in a computing sub-context of a process. The terms “thread” and “process” may be used interchangeably herein when a process includes only one thread.
As used herein, the term “network protocol” refers to a set of rules, conventions, and/or schemas that govern how nodes exchange information over a network. The set may define, for example, a convention and/or a data structure. The term “network path” as used herein refers to a sequence of nodes in a network that are communicatively coupled to transmit data in one or more data units of a network protocol between a pair of nodes in the network.
A “data unit”, as the term is used herein, is an entity specified according to a network protocol to transmit data between a pair of nodes in a network path to send the data from a source node to a destination node that includes an identified protocol endpoint of the network protocol. A network protocol explicitly and/or implicitly specifies and/or otherwise identifies a schema that defines one or more of a rule for a format for a valid data unit and a vocabulary for content of a valid data unit. One example of a data unit is an Internet Protocol (IP) packet. The Internet Protocol defines rules for formatting an IP packet that defines a header to identify a destination address that identifies a destination node and a payload portion to include a representation of data to be delivered to the identified destination node. Various address types are specified defining a vocabulary for one or more address portions of an IP data unit. The terms “data unit” “, frame” “, data packet”, and “packet” are used interchangeably herein. One or more data units of a first network protocol may transmit a “message” of a second network protocol. For example, one or more data units of the IP protocol may include a TCP message. In another example, one or more TCP data units may transmit an HTTP message. A message may be empty.
How data is packaged in one more data units for a network protocol may vary as the data traverses a network path from a source node to a destination node. Data may be transmitted in a single data unit between two consecutive nodes in a network path. Additionally, data may be exchanged between a pair of consecutive nodes in several data units each including a portion of the data. Data received in a single data unit by a node in a network path may be split into portions included in several respective data units to transmit to a next node in the network path. Portions of data received in several data units may be combined into a single data unit to transmit by a node in a network path. For purposes of describing the subject matter, a data unit in which data is received by a node is referred to as a data unit than a data unit in which the data is forwarded by the node.
A “protocol address”, as the term is used herein, for a network protocol is an identifier of a protocol endpoint that may be represented in a data unit of the network protocol. For example, 192.168.1.1 is an IP protocol address represented in a human readable format that may be represented in an address portion of an IP header to identify a source and/or a destination IP protocol endpoint. A protocol address differs from a symbolic identifier, defined below, in that a symbolic identifier, with respect to a network protocol, maps to a protocol address. Thus, “www.mynode.com” may be a symbolic identifier for a node in a network when mapped to the protocol address 192.168.1.1. An identifier may be both a symbolic identifier and a protocol address depending on its role with respect to its use for a particular network protocol.
Since a protocol endpoint is included in a node and is accessible via a network via a network interface, a protocol address identifies a node and identifies a network interface of the node. A network interface may include one or more NICs operatively coupled to a network.
A node in a pair of nodes in a network path at one end of the sequence of nodes in the network path and/or the other end is referred to herein as a “path end node”. Note that a node may have two NICs with one NIC at each end of a network path. A network path may be included as a portion of another network path that communicatively couples a same pair of nodes. Data may be transmitted via the sequence of nodes in a network path between path end nodes communicatively coupled via the network path. Data may be transmitted in one or both directions depending on an ordering of the nodes in the sequence.
The term “hop” as used herein refers to a pair of consecutive nodes in a network path to transmit, via a network protocol, data sent from a source node to a destination node. A “hop path” is thus a sequence of hops in a network that respectively include a sequence of pairs of consecutive nodes included in transmitting data from a first path end node of the network path to a second path end node of the network path.
The term “path-based protocol address” as used herein refers to a protocol address for a network protocol that includes one or more path segment identifiers that identify one or more respective portions of a network path identified by the path-based protocol address. A “node-based protocol address” is a path-based protocol address that includes a plurality of node identifiers that identify a sequence of nodes in a network path. A “network-interface-based protocol address” is a path-based protocol address that includes a plurality of network interface identifiers that identify a sequence of network interfaces in a network path. A “NIC-based protocol address” is a type of network-interface-based protocol address that includes a plurality of identifiers that identify a sequence of network interface components. A “hop-based protocol address” is a type path-based protocol address since a hop is a type of network path.
Given the above definitions, note that the terms “network path” and “hop” may be defined in terms of network interfaces. A “network path” and a “hop path” include a sequence of network interfaces in a network that are included in transmitting data between a pair of path end nodes in the network. A “hop” refers to at least part of a network path that includes a pair of consecutive network interfaces in a sequence of network interfaces in a network path. A “network path” is thus a sequence of hops in a network that respectively includes a sequence of pairs of consecutive network interfaces included in transmitting data from a first path end node of the network path to a second path end node of the network path.
The term “network topology” or “topology”, for short, as used herein refers to a representation of protocol endpoints and/or nodes in a network, and representations of hops representing communicative couplings between and/or among the protocol endpoints and/or nodes in the network. A network may have different network topologies with respect to different network protocols. A network topology may represent physical communicative couplings between nodes in the network. A network topology may represent logical couplings between protocol endpoints and/or nodes of a particular network protocol or a particular type of network protocol.
The domain name system (DNS) of the Internet operates based on an application layer protocol defined by the DNS. The nodes in the DNS are communicatively coupled via the DNS protocol and may be represented by a logical network topology. A DNS system includes nodes connected via the DNS protocol. The DNS system has a network topology defined by nodes that include protocol endpoints of the DNS protocol. In still another example, a token-ring network has a circular topology at the link layer, but may have a star topology at the physical layer.
As used herein, an “entity-specific address space” refers to an address space defined for a specific entity where the addresses in the address space operate as identifiers in the context of the entity. An address from an entity-specific address space is referred to herein as an “entity-specific address”. An address is “entity-specific” in that what it identifies is based on the entity to which it is specific. Another address having the same form and content may identify an entity when in an address space specific to another entity. Addresses in an entity-specific address space operate as identifiers in the context of an entity to which they are “specific” as defined by the specific association of the address space and the entity. Without knowledge of the entity to which an entity-specific address space is specific, what an address in the entity-specific address space identifies is indeterminate. The terms “entity-specific address” and “entity-specific identifier” are used interchangeably herein. An entity-specific address may identify an entity included in the entity to which the address is specific or may identify an entity external to the entity to which the address is specific. The fact that an address is entity-specific does not define a scope for the address.
A portion of a network is a type of entity. A type of entity-specific address space described herein is a scope-specific address space. As used herein, a “scope-specific address space”, specific to a particular region of a network, is an address space defined for the particular network region, where an address in the scope-specific protocol address operates as identifier, according to a network protocol, of a protocol endpoint in a node outside of the particular region when processed in the context of a node in the particular region. The region is indicated by the span of an indicated scope. The terms “region” and “zone” are used interchangeably herein. An address from a scope-specific address space is referred to herein as a “scope-specific protocol address”. An address is “scope-specific” in that what protocol endpoint it identifies depends on the region to which it is specific. Another address having the exact same form and content may identify a protocol endpoint when in an address space that is specific to another region. A protocol address in a scope-specific address space serves as an identifier in the context of a node in a region to which the scope-specific address space is “specific” as defined by an association of the address space and the region indicated by the scope. Without knowledge of the particular region to which a scope-specific address space is specific, what a scope-specific protocol address in the scope-specific address space identifies is indeterminate. The terms “scope-specific protocol address” and “scope-specific protocol identifier” are used interchangeably herein. Types of scope-specific address spaces indicating exemplary spans include site-specific, LAN-specific, subnet-specific, city-specific, business-specific, and node-specific.
For a network protocol, an address in a scope-specific address space serves as an identifier of a protocol endpoint in a node. Data may be received via the protocol endpoint from a network via one or more network interfaces that operatively couple the node to the network. Data may be sent via the protocol endpoint to transmit over the network via the one or more network interfaces in the node. Since a protocol endpoint of a network protocol is included in a node and is accessible via a network via a network interface, a protocol address identifying the protocol endpoint also identifies the node and identifies a network interface of the node.
As used herein, a “node-specific address space” is a scope-specific address space defined for a specific node in a network, where the addresses in the node-specific address space operate as identifiers of nodes and/or network interfaces in the network when processed in the context of the specific node. An address from a node-specific address space is referred to herein as a “node-specific address”. An address is “node-specific” in that what it identifies depends on the node to which is defined as specific. Another address having the exact same form and content may identify a node when in an address space specific to another node. Addresses in a node-specific address space operate as identifiers in the context of a node to which they are “specific” as defined by the specific association of the address space and the node. Without knowledge of the node to which a node-specific address space is specific, addresses in the node-specific address space are indeterminate. The terms “node-specific address” and “node-specific identifier” are used interchangeably herein. A node-specific address space is a type of scope-specific address space.
The term “node” is defined above. Note that an identifier of a network interface in a network also identifies a node that includes the network interface. Thus, a network interface-specific address is also a node-specific address. Network interfaces in a node may have their own respective network interface-specific address spaces that are also node-specific. The network interface-specific address spaces may be combined to form a node-specific address space and/or may be managed as separate address spaces. The adjectives “node-specific” and “network interface-specific” may be used interchangeably.
A scope-specific identifier differs from a scoped address as described in “Request for Comments” (RFC) document RFC 4007 by S. Deering, et al, titled “IPv6 Scoped Address Architecture”, published by the IETF in December, 2006 and further described in application Ser. No. 11/962,285, by the present inventor, filed on 2007 Dec. 21, entitled “Methods and Systems for Sending Information to a zone Included in an Internet Network”. A scoped address space is shared by nodes in a given scope. While a link-local scoped address is specific to a particular node, a link-local scoped address simply identifies a network interface component local to the particular node. A loop-back internet address is specific to a node as well. Neither link-local scoped addresses nor loop-back addresses identify one node to another. As such, neither serves as a node-specific identifier as defined above.
A “scoped address” is described by RFC 3513 and RFC 4007 as an identifier that, in a particular region of a network, serves as a protocol address of a network interface and/or a node in the particular region. The extent of the particular region is referred to as the scope of the region and thus the scope within which the identifier serves as a protocol address. A particular region included within a scope is indicated by its span. A scoped address is a valid protocol address only within a particular region as indicated by the address's indicated scope. Examples of scope indicators include node-scope where identifiers are valid only to a single node in the indicated span, LAN-scope where identifiers are valid for nodes in the span of a particular LAN, and subnet-scope where identifiers are valid only for nodes in a particular subnet. RFC 3513 currently defines support for link-local scope, site-local scope, and global scope. A data unit transmitted with a scoped address should not be delivered to node that does not have a network interface in the span indicated by the scope.
“Path information” is any information that identifies a network path and/or a hop path for data transmitted via one a specified network protocols. Path information may be identified by identifying network interfaces, NICs, nodes, and/or hops included in a network path. “Address information” is any information that identifies a protocol address that, for a network protocol, identifies a protocol endpoint. Address information may identify a unicast protocol address for a network protocol. In identifying a protocol endpoint, a protocol address identifies a node and a network interface.
Those skilled in the art will understand upon reading the descriptions herein that the subject matter disclosed herein is not restricted to the network protocols described and/or their corresponding OSI layers. For ease of illustration, the subject matter is described in terms of protocols that correspond to OSI layer three, also referred to as network layer protocols, in general. Particular descriptions are based on versions of the Internet Protocol (IP). Address information may identify one or more protocol addresses. Exemplary protocol addresses include IP addresses, IPX addresses, DECNet addresses, VINES Internet Protocol addresses, and Datagram Delivery Protocol (DDP) addresses, HTTP URLS, TCP port and IP address pairs, and the like.
The term “path-based address” is defined above. A “node-based address” is a path-based address where some or all of the address includes node identifiers that identify a sequence of nodes in a network path. A “network-interface-based address” is a path-based address where some or all of the address includes identifiers of network interfaces in a sequence in a network path. A “NIC-based address” is a type of network-interface-based address that identifies a sequence of network interface components. A “hop-based address” is a path-based address where some or all of the address identifies one or more hops in a network path. The protocol address types defined are not mutually exclusive.
The term “metric space”, as used herein, refers to a set, as defined in mathematics, where a distance between elements of the set is defined according to a metric. Metric spaces defined in Euclidean geometry are well-known examples. Those skilled in the art of metric spaces, such as Euclidian spaces, will appreciate that a one-to-one mapping may be determined and/or otherwise identified for mapping addresses from a first coordinate space having a first origin for a metric space to addresses from a second coordinate space having a second origin in the metric space. Given a mapping rule between a first scope-specific address space and a second scope-specific address space and a mapping between the second scope-specific address space and a third scope-specific address space based on a third coordinate space identifying a third origin in the metric space, a mapping from the first coordinate space to the third coordinate space may be determined. A mapping between coordinate spaces for a metric space may be included a coordinate shift and/or a rotation, for example. The mapping may be pre-specified and accessible to the nodes in one or both address spaces. Mapping between locations in a number of different metric spaces is well known in mathematics. For example, a top half of the surface of sphere may be mapped to a plane. Some will further appreciate that some metric spaces may be mapped to other metric spaces. Some of these mappings are one-to-one and/or onto.
An “operating environment” or “computing environment”, as used herein, is an arrangement of hardware and, in some aspects, software that may be further modified, transformed, and/or otherwise configured to include and/or otherwise host an arrangement of components to perform a method of the subject matter described herein. An operating environment includes a processor to execute an instruction included in at least one component of such an arrangement. An operating environment includes and/or is otherwise provided by one or more devices. The operating environment is said to be the operating environment “of” the device and/or devices.
As used herein a “processor” is an instruction execution machine, apparatus, or device. A processor may include one or more electrical, optical, and/or mechanical components that operate in interpreting and executing program instructions. Exemplary processors include one or more microprocessors, digital signal processors (DSPs), graphics processing units, application-specific integrated circuits (ASICs), optical or photonic processors, and/or field programmable gate arrays (FPGAs).
The terms “network node” and “node” in this document both refer to a device having a network interface component (NIC) for operatively coupling the device to a network. Further, the terms “device” and “node” used herein refer to one or more devices and nodes, respectively, providing and/or otherwise included in an operating environment unless clearly indicated otherwise.
As used herein, the term “network protocol” refers to a set of rules and/or conventions that govern how nodes exchange information over a network. The set may define, for example, a convention and/or a data structure. A “data unit”, as the term is used herein, is an entity specified according to a network protocol to transmit data between a pair of nodes in a network path to send the data from a source node to a destination node that includes an identified protocol endpoint of the network protocol. A network protocol explicitly and/or implicitly specifies and/or otherwise identifies a schema that defines one or more of a rule for a format for a valid data unit and a vocabulary for content of a valid data unit. One example of a data unit is an Internet Protocol (IP) packet. The Internet Protocol defines rules for formatting an IP packet that defines a header to identify a destination address that identifies a destination node, and also defines a payload portion to include data to be delivered to the identified destination node. Various address types are specified defining a vocabulary for one or more address fields of an IP data unit. The terms “data unit”, “frame”, “data unit”, and “packet” are used interchangeably herein. One or more data units of a first network protocol may transmit a “message” of a second network protocol. For example, one or more data units of the IP protocol may include a TCP message. In another example, one or more TCP data units may transmit a HTTP message. A message may be empty as may a payload of a data unit.
How data is packaged in one more data units for a network protocol may vary as the data traverses a network path from a source node to a destination node. Data may be transmitted in a single data unit between two consecutive nodes in a network path. Additionally, data may be exchanged between a pair of consecutive nodes in several data units each including a portion of the data. Data received in a single data unit by a node in a network path may be split into portions included in several respective data units to transmit to a next node in the network path. Portions of data received in several data units may be combined into a single data unit to transmit by a node in a network path. For purposes of describing the subject matter, a data unit in which data is received by a node is referred to as a different data unit than a data unit in which the data is forwarded by the node.
A “protocol address”, as the term is used herein, for a network protocol is an identifier of a protocol endpoint of the network protocol when included in an address field of a data unit of the network protocol. For example, 192.168.1.1 is an IP protocol address represented in a human readable format that may be represented in an address field of a header of an IP packet (i.e. an IP data unit) to identify a source and/or a destination IP protocol endpoint. A protocol address differs from a symbolic identifier, defined below, in that a symbolic identifier, with respect to a network protocol, maps to a protocol address. Thus, “www.mynode.com” may be a symbolic identifier for a node in a network when mapped to the protocol address 192.168.1.1. An identifier may be both a symbolic identifier and a protocol address depending on its role with respect to its use for a particular network protocol.
Since a protocol endpoint is accessible by way of a network via a network interface in a node, a protocol address may be processed to identify a node and may be processed to identify a network interface of the node. A network interface may include one or more NICs operatively coupled to a network.
The term “network path” as used herein refers to a sequence of nodes in a network that are communicatively coupled to transmit data in one or more data units of one or more network protocols between a pair of nodes in the network. A node in a pair of nodes in a network path at one end of the sequence of nodes in the network path and/or the other end is referred to herein as a “path end node”. Note that a node may have two NICs with one NIC at each end of a network path. A network path may be included as a portion of another network path that communicatively couples a same pair of nodes. Data may be transmitted via the sequence of nodes in a network path between path end nodes communicatively coupled via the network path. Data may be transmitted in one or both directions depending on an ordering of the nodes in the sequence.
For a network protocol, the term “hop”, as used herein, refers to a pair of consecutive nodes in a network path to transmit, via the network protocol, data sent from a source node to a destination node. A “hop path” is thus a sequence of hops in a network that respectively include a sequence of pairs of consecutive nodes included in transmitting data from a first path end node of the network path to a second path end node of the network path.
The term “path-based protocol address” as used herein refers to a protocol address for a network protocol that includes one or more path segment identifiers that identify one or more respective portions of a network path identified by the path-based protocol address. A “node-based protocol address” is a path-based protocol address that includes a plurality of node identifiers that identify a sequence of nodes in a network path. A “network-interface-based protocol address” is a path-based protocol address that includes a plurality of network interface identifiers that identify a sequence of network interfaces in a network path. A “NIC-based protocol address” is a type of network-interface-based protocol address that includes a plurality of identifiers that identify a sequence of network interface components. A “hop-based protocol address” is a type path-based protocol address since a hop is a type of network path.
Given the above definitions, note that the terms “network path” and “hop” may be defined in terms of network interfaces. A “network path” and a “hop path” include a sequence of network interfaces in a network that are included in transmitting data between a pair of path end nodes in the network. A “hop” refers to at least part of a network path that includes a pair of consecutive network interfaces in a sequence of network interfaces in a network path. A “network path” is thus a sequence of hops in a network that respectively includes a sequence of pairs of consecutive network interfaces included in transmitting data from a first path end node of the network path to a second path end node of the network path.
The term “network topology” or “topology”, for short, as used herein refers to a representation of protocol endpoints, network interfaces, and/or nodes in a network, and representations of communicative couplings between and/or among the protocol endpoints, network interfaces, and/or nodes in the network. A network may have different network topologies with respect to different network protocols and/or with respect to different attributes of a same network protocol. A network topology may represent physical communicative couplings between protocol endpoints, network interfaces, and/or nodes in the network. A network topology may represent logical couplings between protocol endpoints, network interfaces, and/or nodes of a particular network protocol or a particular type of network protocol.
As used herein, an “entity-specific address space” refers to an address space defined for a specific entity where the addresses in the address space operate as identifiers in the context of the entity. An address from an entity-specific address space is referred to herein as an “entity-specific address”. An address is “entity-specific” in that what it identifies is based on the entity to which it is specific. An address may identify one entity in one address space specific to a particular entity and may identify a different entity in another address space specific to a different entity. Addresses in an entity-specific address space operate as identifiers in the context of an entity to which they are “specific” as defined by the specific association of the address space and the entity. Without knowledge of the entity to which an entity-specific address space is specific, what an address in the entity-specific address space identifies is indeterminate. The terms “entity-specific address” and “entity-specific identifier” are used interchangeably herein.
An entity-specific address may identify an entity included in the entity to which the address is specific. Such as an address is said to be a “scoped”. An entity-specific address may identify an entity external to the entity to which the address is specific. Such as address is said to be “scope-specific”. The fact that an address is entity-specific does not define a scope for the address.
A portion of a network is a type of entity. A type of entity-specific address space described herein is a scope-specific address space. As used herein, a “scope-specific address space”, specific to a particular region of a network, is an address space defined for the particular network region, where an address in the scope-specific protocol address operates as an identifier, according to a network protocol, of a protocol endpoint in a node outside of the particular region when processed in the context of a node in the particular region. The region is indicated by the span of an indicated scope. The terms “region” and “zone” are used interchangeably herein. An address from a scope-specific address space is referred to herein as a “scope-specific protocol address”. An address is “scope-specific” in that what protocol endpoint it identifies depends on the region to which it is specific. Another address having the exact same form and content may identify a different protocol endpoint when in an address space that is specific to another region. A protocol address in a scope-specific address space serves as an identifier in the context of a node in a region to which the scope-specific address space is “specific” as defined by an association of the address space and the region indicated by the scope. Without knowledge of the particular region to which a scope-specific address space is specific, what a scope-specific protocol address in the scope-specific address space identifies is indeterminate. The terms “scope-specific protocol address” and “scope-specific protocol identifier” are used interchangeably herein. Types of scope-specific address spaces indicating exemplary spans include site-specific, LAN-specific, subnet-specific, city-specific, business-specific, and node-specific.
For a network protocol, an address in a scope-specific address space serves as an identifier of a protocol endpoint in a node. Data may be received via the protocol endpoint from a network via one or more network interfaces that operatively couple the node to the network. Data may be sent via the protocol endpoint to transmit over the network via the one or more network interfaces in the node. Since a protocol endpoint of a network protocol is included in a node and is accessible via a network via a network interface, a protocol address identifying the protocol endpoint also identifies the node and identifies a network interface of the node.
As used herein, a “node-specific address space” is a scope-specific address space defined for a specific node in a network, where the addresses in the node-specific address space operate as identifiers of nodes and/or network interfaces in the network when processed in the context of the specific node. An address from a node-specific address space is referred to herein as a “node-specific address”. An address is “node-specific” in that what it identifies depends on the node to which is defined as specific. Another address having the exact same form and content may identify a different node when in an address space specific to another node. Addresses in a node-specific address space operate as identifiers in the context of a node to which they are “specific” as defined by the specific association of the address space and the node. Without knowledge of the node to which a node-specific address space is specific, addresses in the node-specific address space are indeterminate. The terms “node-specific address” and “node-specific identifier” are used interchangeably herein. A node-specific address space is a type of scope-specific address space.
The term “node” is defined above. Note that an identifier of a network interface in a network also identifies a node that includes the network interface. Thus, a network interface-specific address is also a node-specific address. Network interfaces in a node may have their own respective network interface-specific address spaces that are also node-specific. The network interface-specific address spaces may be combined to form a node-specific address space and/or may be managed as separate address spaces. The adjectives “node-specific” and “network interface-specific” may be used interchangeably.
A scope-specific identifier differs from a scoped address. Scoped addresses are described in RFC 3007, RFC 3513, and further described in application Ser. No. 11/962,285, by the present inventor, filed on 2007 Dec. 21, entitled “Methods and Systems for Sending Information to a Zone Included in an Internet Network”. A scoped address space is shared by nodes in a given scope. While a link-local scoped address is specific to a particular node, a link-local scoped address simply identifies a network interface component local to the particular node. A loop-back internet address is specific to a node as well. Neither link-local scoped addresses nor loop-back addresses identify one node to another. As such, neither serves as a node-specific identifier as defined above.
A “scoped address” is described by RFC 3513 and RFC 3007 as an identifier that, in a particular region of a network, serves as a protocol address of a network interface and/or a node in the particular region. The extent of the particular region is referred to as the scope of the region and thus the scope within which the identifier serves as a protocol address. A particular region included within a scope is indicated by its span. A scoped address is a valid protocol address only within a particular region as indicated by the address's indicated scope. Examples of scope indicators include node-scope where identifiers are valid only to a single node in the indicated span, LAN-scope where identifiers are valid for nodes in the span of a particular LAN, and subnet-scope where identifiers are valid only for nodes in a particular subnet. RFC 3513 currently defines support for link-local scope, site-local scope, and global scope. A data unit transmitted with a scoped address should not be delivered to node that does not have a network interface in the span indicated by the scope.
“Path information” is any information that identifies a network path, such as a hop path, for data transmitted via one or more specified network protocols. Path information may be identified by identifying network interfaces, NICs, nodes, and/or hops included in a network path. “Address information” is any information that identifies a protocol address that, for a network protocol, identifies a protocol endpoint. Address information may identify a unicast protocol address for a network protocol. In identifying a protocol endpoint, a protocol address identifies a node and a network interface.
Those skilled in the art will understand upon reading the descriptions herein that the subject matter disclosed herein is not restricted to the network protocols described and/or their corresponding OSI layers. For ease of illustration, the subject matter is described in terms of protocols that correspond to OSI layer three, also referred to as network layer protocols, in general. Particular descriptions are based on versions of the Internet Protocol (IP). Address information may identify one or more protocol addresses. Exemplary protocol addresses include IP addresses, IPX addresses, DECNet addresses, VINES Internet Protocol addresses, and Datagram Delivery Protocol (DDP) addresses, HTTP URLS, TCP port and IP address pairs, and the like.
The term “metric space”, as used herein, refers to a set, as defined in mathematics, where a distance between elements of the set is defined according to a metric. Metric spaces defined in Euclidean geometry are well-known examples. Those skilled in the art of metric spaces, such as Euclidian spaces, will appreciate that a one-to-one mapping may be determined and/or otherwise identified for mapping addresses from a first coordinate space having a first origin for a metric space to addresses from a second coordinate space having a second origin in the metric space. Given a mapping rule between a first scope-specific address space and a second scope-specific address space and a mapping between the second scope-specific address space and a third scope-specific address space based on a third coordinate space identifying a third origin in the metric space, a mapping from the first coordinate space to the third coordinate space may be determined. A mapping between coordinate spaces for a metric space may be include, for example, coordinate shift and/or a rotation, for example. The mapping may be pre-specified and accessible to the nodes in one or both address spaces. Mapping between locations in a number of different metric spaces is well known in mathematics. For example, a top half of the surface of sphere may be mapped to a plane. Some will further appreciate that some metric spaces may be mapped to other metric spaces. Some of these mappings are one-to-one and/or onto.
As used herein, the term “software component” refers to any data representation that includes and/or may be translated to include one or more instructions executable by a processor. A software component may optionally include associated data that does not represent an instruction executable by a processor.
An “execution environment”, as used herein, is an arrangement of hardware and, in some aspects, software that may be further modified, transformed, and/or otherwise configured to include and/or otherwise host an arrangement of components to perform a method of the subject matter described herein. An execution environment includes a processor to execute an instruction included in at least one component of such an arrangement. An execution environment includes and/or is otherwise provided by one or more devices. The execution environment is said to be the execution environment “of” the device and/or devices. Exemplary devices included in and/or otherwise providing suitable execution environments that may be adapted, programmed, and/or otherwise modified according to the subject matter include a workstation, a desktop computer, a laptop or notebook computer, a server, a handheld computer, a mobile telephone or other portable telecommunication device, a media playing device, a gaming system, a tablet computer, a portable electronic device, a handheld electronic device, a multiprocessor device, a distributed system, a consumer electronic device, a router, a switch, a bridge, a network server, or any other type and/or form of computing, telecommunications, network, and/or media device that is suitable to perform the subject matter described herein. Those skilled in the art will understand that the components illustrated in
As used herein a “processor” is an instruction execution machine, apparatus, or device. A processor may include one or more electrical, optical, and/or mechanical components that operate in interpreting and executing program instructions. Exemplary processors include one or more microprocessors, digital signal processors (DSPs), graphics processing units, application-specific integrated circuits (ASICs), optical or photonic processors, and/or field programmable gate arrays (FPGAs).
The terms “network node” and “node” in this document both refer to a device having a network interface component for operatively coupling the device to a network. Further, the terms “device” and “node” used herein refer to one or more devices and nodes, respectively, providing and/or otherwise included in an execution environment unless clearly indicated otherwise.
A computer program may include one or more software components. As used herein, the term “software component” refers to any data representation that may be and/or may be translated into a set of machine code instructions and may optionally include associated data. Software component representations other than machine code include object code, byte code, and source code. Object code includes a set of instructions and/or data elements that either are prepared to link prior to loading or are loaded into an execution environment. When in an execution environment, object code may include references resolved by a linker and/or may include one or more unresolved references. The context in which this term is used will make clear the state of the object code when it is relevant. This definition can include machine code and virtual machine code, such as Java™ byte code. A software component may include one or more components. As used herein, the terms “application”, and “service” may be realized in one or more software components and/or in one or more hardware components.
Software components typically include instructions executed by a processor in a computing context referred to as a “process”. A process may include one or more “threads”. A “thread” includes a sequence of instructions executed by a processor in a computing sub-context of a process. The terms “thread” and “process” may be used interchangeably herein when a process includes only one thread.
As used herein, the term “network protocol” refers to a set of rules, conventions, and/or schemas that govern how nodes exchange information over a network. The set may define, for example, a convention and/or a data structure. For example, data for transmitting from a source node to a destination node may be included in a payload portion of a data unit of a particular network protocol. The network protocol may define a format that identifies the payload based on one or more valid data structures for a data unit. For example, a payload portion may be identified by a location with respect to the start of a data unit or relative to another portion of the data unit. Alternatively or additionally, the network protocol may defined a vocabulary defining a keyword, a bit pattern, and/or other detectable marker that when detected identifies a payload or part of a payload in a data unit. The network protocol may define one or more format rules and/or vocabulary rules that an in-data component may detect in identifying address information in a data unit. The term “schema” refers to a definition of a structure and/or a vocabulary for constructing and/or detecting a valid data unit with respect to a network protocol for which the schema is defined. For example, both an IPv4 packet and an IPv6 packet are specified according to a schema that specifies rules for including address information in a destination protocol address field and in a source protocol address field in an IP header based on location and size.
A “data unit”, as the term is used herein, is an entity specified according to a network protocol to transmit data between a pair of nodes in a network path in sending the data from a source node to a destination node that includes an identified protocol endpoint of the network protocol. A network protocol explicitly and/or implicitly specifies and/or otherwise identifies a schema that defines one or more of a rule for a format for a valid data unit and a vocabulary for content of a valid data unit. One example of a data unit is an Internet Protocol (IP) packet. The Internet Protocol defines rules for formatting an IP packet that defines a header to identify a destination address that identifies a destination node and a payload portion to include a representation of data to be delivered to the identified destination node. Various address types are specified defining a vocabulary for one or more address portions of an IP data unit. The terms “data unit”, “frame”, “data packet”, and “packet” are used interchangeably herein. One or more data units of a first network protocol may transmit a “message” of a second network protocol. For example, one or more data units of the IP protocol may include a TCP message. In another example, one or more TCP data units may transmit a HTTP message. A message may be empty.
How data is packaged in one more data units for a network protocol may vary as the data traverses a network path from a source node to a destination node. Data may be transmitted in a single data unit between two consecutive nodes in a network path. Additionally, data may be exchanged between a pair of consecutive nodes in several data units each including a portion of the data. Data received in a single data unit by a node in a network path may be split into portions included in several respective data units to transmit to a next node in the network path. Portions of data received in several data units may be combined into a single data unit to transmit by a node in a network path. For purposes of describing the subject matter, a data unit in which data is received by a node is referred to as a different data unit than a data unit in which the data is forwarded by the node.
A “protocol address”, as the term is used herein, for a network protocol is an identifier of a protocol endpoint that may be represented in a data unit of the network protocol. For example, “192.168.1.1” is an IP protocol address represented in a human readable format that may be represented in an address portion of an IP header to identify a source and/or a destination IP protocol endpoint. A protocol address differs from a symbolic identifier, defined below, in that a symbolic identifier, with respect to a network protocol, maps to a protocol address. Thus, “www.mynode.com” may be a symbolic identifier for a node in a network when mapped to the protocol address “192.168.1.1”. An identifier may be both a symbolic identifier and a protocol address depending on its role with respect to its use for a particular network protocol.
Since a protocol endpoint is accessible by way of a network via a network interface in a node, a protocol address identifies a node and identifies a network interface of the node. A network interface may include one or more NICs operatively coupled to a network.
A node in a pair of nodes in a network path at one end of the sequence of nodes in the network path and/or the other end is referred to herein as a “path end node”. Note that a node may have two NICs with one NIC at each end of a network path. A network path may be included as a portion of another network path that communicatively couples a same pair of nodes. Data may be transmitted via the sequence of nodes in a network path between path end nodes communicatively coupled via the network path. Data may be transmitted in one or both directions depending on an ordering of the nodes in the sequence.
The term “network path” as used herein refers to a sequence of nodes in a network that are communicatively coupled to transmit data in one or more data units of a network protocol between a pair of nodes in the network.
The term “hop” as used herein refers to a pair of consecutive nodes in a network path to transmit, via a network protocol, data sent from a source node to a destination node. A “hop path” is thus a sequence of hops in a network that respectively include a sequence of pairs of consecutive nodes included in transmitting data from a first path end node of the network path to a second path end node of the network path. A “network path” is thus a sequence of hops in a network that respectively includes a sequence of pairs of consecutive network interfaces included in transmitting data from a first path end node of the network path to a second path end node of the network path.
Given the above definitions, note that the terms “network path” and “hop” may be defined in terms of network interfaces. A “network path” is a sequence of network interfaces in a network to transmit data in one or more data units of a specified network protocol between a pair of path end nodes in the network. A “hop” refers to a pair of consecutive network interfaces, in a pair of nodes, in a sequence of network interfaces in a network path. A hop in a sequence in a network path corresponds to a pair of network interfaces in the sequence of network interfaces in the network path.
The term “path-based protocol address” as used herein refers to a protocol address for a network protocol that includes one or more path segment identifiers that identify one or more respective portions of a network path identified by the path-based protocol address. A “node-based protocol address” is a path-based protocol address that includes a plurality of node identifiers that identify a sequence of nodes in a network path. A “network-interface-based protocol address” is a path-based protocol address that includes a plurality of network interface identifiers that identify a sequence of network interfaces in a network path. A “NIC-based protocol address” is a type of network-interface-based protocol address that includes a plurality of identifiers that identify a sequence of network interface components. A “hop-based protocol address” is a type path-based protocol address since a hop is a type of network path. The protocol address types defined are not mutually exclusive.
The term “network topology” or “topology”, for short, as used herein refers to a representation of protocol endpoints, network interfaces, and/or nodes in a network, and representations of communicative couplings between and/or among the protocol endpoints, network interfaces, and/or nodes in the network. A network may have different network topologies with respect to different network protocols and/or address spaces. A network topology may represent physical communicative couplings between protocol endpoints, network interfaces, and/or nodes in the network. A network topology may represent logical couplings between protocol endpoints, network interfaces, and/or nodes of a particular network protocol or a particular type of network protocol.
The domain name system (DNS) of the Internet operates based on an application layer protocol defined by the DNS. The nodes in the DNS are communicatively coupled via the DNS protocol and may be represented by a logical network topology. A DNS system includes nodes connected via the DNS protocol. The DNS system has a network topology defined by nodes that include protocol endpoints of the DNS protocol. Such a topology may also include nodes that relay DNS protocol data units between and/or among nodes with DNS protocol endpoints. In still another example, a token-ring network has a circular topology at the link layer, but may have a star topology at the physical layer.
As used herein, an “entity-specific address space” refers to an address space defined for a specific entity where the addresses in the address space operate as identifiers in the context of the entity. An address from an entity-specific address space is referred to herein as an “entity-specific address”. An address is “entity-specific” in that what it identifies is based on the entity to which it is specific. An address may identify one entity in one address space specific to a particular entity and may identify a different entity in another address space specific to a different entity. Addresses in an entity-specific address space operate as identifiers in the context of an entity to which they are “specific” as defined by the specific association of the address space and the entity. Without knowledge of the entity to which an entity-specific address space is specific, what an address in the entity-specific address space identifies is indeterminate. The terms “entity-specific address” and “entity-specific identifier” are used interchangeably herein. An entity-specific address may identify an entity included in the entity to which the address is specific. Such as an address is said to be a “scoped”. An entity-specific address identifies an entity external to the entity to which the address is specific. Such as address is said to be “scope-specific”. The fact that an address is entity-specific does not define a scope for the address.
A portion of a network is a type of entity. A type of entity-specific address space described herein is a scope-specific address space. As used herein, a “scope-specific address space”, specific to a particular region of a network, is an address space defined for the particular network region, where an address in the scope-specific protocol address operates as an identifier, according to a network protocol, of a protocol endpoint in a node outside of the particular region when processed in the context of a node in the particular region. The region is indicated by the span of an indicated scope. The terms “region” and “zone” are used interchangeably herein. An address from a scope-specific address space is referred to herein as a “scope-specific protocol address”. An address is “scope-specific” in that what protocol endpoint it identifies depends on the region to which it is specific. Another address having the exact same form and content may identify a different protocol endpoint when in an address space that is specific to another region. A protocol address in a scope-specific address space serves as an identifier in the context of a node in a region to which the scope-specific address space is “specific” as defined by an association of the address space and the region indicated by the scope. Without knowledge of the particular region to which a scope-specific address space is specific, what a scope-specific protocol address in the scope-specific address space identifies is indeterminate. The terms “scope-specific protocol address” and “scope-specific protocol identifier” are used interchangeably herein. Types of scope-specific address spaces indicating exemplary spans include site-specific, LAN-specific, subnet-specific, city-specific, business-specific, and node-specific.
For a network protocol, an address in a scope-specific address space serves as an identifier of a protocol endpoint in a node. Data may be received via the protocol endpoint from a network via one or more network interfaces that operatively couple the node to the network. Data may be sent via the protocol endpoint to transmit over the network via the one or more network interfaces in the node. Since a protocol endpoint of a network protocol is included in a node and is accessible via a network via a network interface, a protocol address identifying the protocol endpoint also identifies the node and identifies a network interface of the node.
As used herein, a “node-specific address space” is a scope-specific address space defined for a specific node in a network, where the addresses in the node-specific address space operate as identifiers of nodes and/or network interfaces in the network when processed in the context of the specific node. An address from a node-specific address space is referred to herein as a “node-specific address”. An address is “node-specific” in that what it identifies depends on the node to which is defined as specific. Another address having the exact same form and/or content may identify a different node when in an address space specific to another node. Addresses in a node-specific address space operate as identifiers in the context of a node to which they are “specific” as defined by the specific association of the address space and the node. Without knowledge of the node to which a node-specific address space is specific, addresses in the node-specific address space are indeterminate. The terms “node-specific address” and “node-specific identifier” are used interchangeably herein. A node-specific address space is a type of scope-specific address space.
The term “node” is defined above. Note that an identifier of a network interface in a network also identifies a node that includes the network interface. Thus, a network interface-specific address is also a node-specific address. Network interfaces in a node may have their own respective network interface-specific address spaces that are also node-specific. The network interface-specific address spaces may be combined to form a node-specific address space and/or may be managed as separate address spaces. The adjectives “node-specific” and “network interface-specific” may be used interchangeably.
A scope-specific identifier differs from a scoped address. Scoped addresses are described in RFC 4007, RFC 3513, and further described in application Ser. No. 11/962,285, by the present inventor, filed on 2007 Dec. 21, entitled “Methods and Systems for Sending Information to a Zone Included in an Internet Network”. A scoped address space is shared by nodes in a given scope. While a link-local scoped address is specific to a particular node, a link-local scoped address simply identifies a network interface component local to the particular node. A loop-back internet address is specific to a node as well. Neither link-local scoped addresses nor loop-back addresses identify one node to another. As such, neither serves as a node-specific identifier as defined above.
A “scoped address” is described by RFC 3513 and RFC 4007 as an identifier that, in a particular region of a network, serves as a protocol address of a network interface and/or a node in the particular region. The extent of the particular region is referred to as the scope of the region and thus the scope within which the identifier serves as a protocol address. A particular region included within a scope is indicated by its span. A scoped address is a valid protocol address only within a particular region as indicated by the address's indicated scope. Examples of scope indicators include node-scope where identifiers are valid only to a single node in the indicated span, LAN-scope where identifiers are valid for nodes in the span of a particular LAN, and subnet-scope where identifiers are valid only for nodes in a particular subnet. RFC 3513 currently defines support for link-local scope, site-local scope, and global scope. A data unit transmitted with a scoped address should not be delivered to node that does not have a network interface in the span indicated by the scope.
“Path information” is any information that identifies a network path, such as a hop path, for data transmitted via one or more specified network protocols. Path information may be identified by identifying network interfaces, NICs, nodes, and/or hops included in a network path.
“Address information” is any information that identifies a protocol address that, for a network protocol, identifies a protocol endpoint. Address information may identify a unicast protocol address for a network protocol. In identifying a protocol endpoint, a protocol address identifies a node and a network interface.
For ease of illustration, the description that follows focuses on IP networks and protocols in the TCP/IP suite due to their wide use and because they are well-known in the art. Those skilled in the art will understand upon reading the descriptions herein that the subject matter disclosed herein is not restricted to the network protocols described and/or their corresponding OSI layers. For example, link layer protocols and link-layer networks are considered to be within the scope of the subject matter of this disclosure.
The term “metric space”, as used herein, refers to a set, as defined in mathematics, where a distance between elements of the set is defined according to a metric. Metric spaces defined in Euclidean geometry are well-known examples. Those skilled in the art of metric spaces, such as Euclidian spaces, will appreciate that a one-to-one mapping may be determined and/or otherwise identified for mapping addresses from a first coordinate space having a first origin for a metric space to addresses from a second coordinate space having a second origin in the metric space. Given a mapping rule between a first scope-specific address space and a second scope-specific address space and a mapping between the second scope-specific address space and a third scope-specific address space based on a third coordinate space identifying a third origin in the metric space, a mapping from the first coordinate space to the third coordinate space may be determined. A mapping between coordinate spaces for a metric space may include, for example, coordinate shift and/or a rotation. The mapping may be pre-specified and accessible to the nodes in one or both address spaces. Mapping between locations in a number of different metric spaces is well known in mathematics. For example, a top half of the surface of sphere may be mapped to a plane. Some will further appreciate that some metric spaces may be mapped to other metric spaces. Some of these mappings are one-to-one and/or on-to.
An “execution environment”, as used herein, is an arrangement of hardware and, in some aspects, software that may be further modified, transformed, and/or otherwise configured to include and/or otherwise host an arrangement of components to perform a method of the subject matter described herein. An execution environment includes a processor to execute an instruction included in at least one component of such an arrangement. An execution environment includes and/or is otherwise provided by one or more devices. The execution environment is said to be the execution environment “of” the device and/or devices. Exemplary devices included in and/or otherwise providing suitable execution environments that may be adapted, programmed, and/or otherwise modified according to the subject matter include a workstation, a desktop computer, a laptop or notebook computer, a server, a handheld computer, a mobile telephone or other portable telecommunication device, a media playing device, a gaming system, a tablet computer, a portable electronic device, a handheld electronic device, a multiprocessor device, a distributed system, a consumer electronic device, a router, a switch, a bridge, a network server, or any other type and/or form of computing, telecommunications, network, and/or media device that is suitable to perform the subject matter described herein. Those skilled in the art will understand that the components illustrated in
As used herein a “processor” is an instruction execution machine, apparatus, or device. A processor may include one or more electrical, optical, and/or mechanical components that operate in interpreting and executing program instructions. Exemplary processors include one or more microprocessors, digital signal processors (DSPs), graphics processing units, application-specific integrated circuits (ASICs), optical or photonic processors, and/or field programmable gate arrays (FPGAs).
The terms “network node” and “node” in this document both refer to a device having a network interface component for operatively coupling the device to a network. Further, the terms “device” and “node” used herein refer to one or more devices and nodes, respectively, providing and/or otherwise included in an execution environment unless clearly indicated otherwise.
As used herein, the term “network protocol” refers to a set of rules, conventions, and/or schemas that govern how nodes exchange information over a network. The set may define, for example, a convention and/or a data structure. For example, data for transmitting from a source node to a destination node may be included in a payload portion of a data unit of a particular network protocol. The network protocol may define a format that identifies the payload based on one or more valid data structures for a data unit. For example, a payload portion may be identified by a location with respect to the start of a data unit or relative to another portion of the data unit. Alternatively or additionally, the network protocol may defined a vocabulary defining a keyword, a bit pattern, and/or other detectable marker that when detected identifies a payload or part of a payload in a data unit. The network protocol may define one or more format rules and/or vocabulary rules that an in-data component may detect in identifying address information in a data unit. The term “schema” refers to a definition of a structure and/or a vocabulary for constructing and/or detecting a valid data unit with respect to a network protocol for which the schema is defined. For example, both an IPv4 packet and an IPv6 packet are specified according to a schema that specifies rules for including address information in a destination protocol address field and in a source protocol address field in an IP header based on location and size.
A “data unit”, as the term is used herein, is an entity specified according to a network protocol to transmit data between a pair of nodes in a network path in sending the data from a source node to a destination node that includes an identified protocol endpoint of the network protocol. A network protocol explicitly and/or implicitly specifies and/or otherwise identifies a schema that defines one or more of a rule for a format for a valid data unit and a vocabulary for content of a valid data unit. One example of a data unit is an Internet Protocol (IP) packet. The Internet Protocol defines rules for formatting an IP packet that defines a header to identify a destination address that identifies a destination node and a payload portion to include a representation of data to be delivered to the identified destination node. Various address types are specified defining a vocabulary for one or more address portions of an IP data unit. The terms “data unit”, “frame”, “data unit”, and “packet” are used interchangeably herein. One or more data units of a first network protocol may transmit a “message” of a second network protocol. For example, one or more data units of the IP protocol may include a TCP message. In another example, one or more TCP data units may transmit a HTTP message. A message may be empty.
How data is packaged in one more data units for a network protocol may vary as the data traverses a network path from a source node to a destination node. Data may be transmitted in a single data unit between two consecutive nodes in a network path. Additionally, data may be exchanged between a pair of consecutive nodes in several data units each including a portion of the data. Data received in a single data unit by a node in a network path may be split into portions included in several respective data units to transmit to a next node in the network path. Portions of data received in several data units may be combined into a single data unit to transmit by a node in a network path. For purposes of describing the subject matter, a data unit in which data is received by a node is referred to as a different data unit than a data unit in which the data is forwarded by the node.
A “protocol address”, as the term is used herein, for a network protocol is an identifier of a protocol endpoint that may be represented in a data unit of the network protocol. For example, “192.168.1.1” is an IP protocol address represented in a human readable format that may be represented in an address portion of an IP header to identify a source and/or a destination IP protocol endpoint. A protocol address differs from a symbolic identifier, defined below, in that a symbolic identifier, with respect to a network protocol, maps to a protocol address. Thus, “www.mynode.com” may be a symbolic identifier for a node in a network when mapped to the protocol address “192.168.1.1”. An identifier may be both a symbolic identifier and a protocol address depending on its role with respect to its use for a particular network protocol.
Since a protocol endpoint is accessible by way of a network via a network interface in a node, a protocol address identifies a node and identifies a network interface of the node. A network interface may include one or more NICs operatively coupled to a network.
A node in a pair of nodes in a network path at one end of the sequence of nodes in the network path and/or the other end is referred to herein as a “path end node”. Note that a node may have two NICs with one NIC at each end of a network path. A network path may be included as a portion of another network path that communicatively couples a same pair of nodes. Data may be transmitted via the sequence of nodes in a network path between path end nodes communicatively coupled via the network path. Data may be transmitted in one or both directions depending on an ordering of the nodes in the sequence.
The term “network path” as used herein refers to a sequence of nodes in a network that are communicatively coupled to transmit data in one or more data units of a network protocol between a pair of nodes in the network.
The term “hop” as used herein refers to a pair of consecutive nodes in a network path to transmit, via a network protocol, data sent from a source node to a destination node. A “hop path” is thus a sequence of hops in a network that respectively include a sequence of pairs of consecutive nodes included in transmitting data from a first path end node of the network path to a second path end node of the network path. A “network path” is thus a sequence of hops in a network that respectively includes a sequence of pairs of consecutive network interfaces included in transmitting data from a first path end node of the network path to a second path end node of the network path.
Given the above definitions, note that the terms “network path” and “hop” may be defined in terms of network interfaces. A “network path” is a sequence of network interfaces in a network to transmit data in one or more data units of a specified network protocol between a pair of path end nodes in the network. A “hop” refers to a pair of consecutive network interfaces, in a pair of nodes, in a sequence of network interfaces in a network path. A hop in a sequence in a network path corresponds to a pair of network interfaces in the sequence of network interfaces in the network path.
The term “path-based protocol address” as used herein refers to a protocol address for a network protocol that includes one or more path segment identifiers that identify one or more respective portions of a network path identified by the path-based protocol address. A “node-based protocol address” is a path-based protocol address that includes a plurality of node identifiers that identify a sequence of nodes in a network path. A “network-interface-based protocol address” is a path-based protocol address that includes a plurality of network interface identifiers that identify a sequence of network interfaces in a network path. A “NIC-based protocol address” is a type of network-interface-based protocol address that includes a plurality of identifiers that identify a sequence of network interface components. A “hop-based protocol address” is a type path-based protocol address since a hop is a type of network path. The protocol address types defined are not mutually exclusive.
The term “network topology” or “topology”, for short, as used herein refers to a representation of protocol endpoints, network interfaces, and/or nodes in a network, and representations of communicative couplings between and/or among the protocol endpoints, network interfaces, and/or nodes in the network. A network may have different network topologies with respect to different network protocols and/or address spaces. A network topology may represent physical communicative couplings between protocol endpoints, network interfaces, and/or nodes in the network. A network topology may represent logical couplings between protocol endpoints, network interfaces, and/or nodes of a particular network protocol or a particular type of network protocol.
The domain name system (DNS) of the Internet operates based on an application layer protocol defined by the DNS. The nodes in the DNS are communicatively coupled via the DNS protocol and may be represented by a logical network topology. A DNS system includes nodes connected via the DNS protocol. The DNS system has a network topology defined by nodes that include protocol endpoints of the DNS protocol. Such a topology may also include nodes that relay DNS protocol data units between and/or among nodes with DNS protocol endpoints. In still another example, a token-ring network has a circular topology at the link layer, but may have a star topology at the physical layer.
As used herein, an “entity-specific address space” refers to an address space defined for a specific entity where the addresses in the address space operate as identifiers in the context of the entity. An address from an entity-specific address space is referred to herein as an “entity-specific address”. An address is “entity-specific” in that what it identifies is based on the entity to which it is specific. An address may identify one entity in one address space specific to a particular entity and may identify a different entity in another address space specific to a different entity. Addresses in an entity-specific address space operate as identifiers in the context of an entity to which they are “specific” as defined by the specific association of the address space and the entity. Without knowledge of the entity to which an entity-specific address space is specific, what an address in the entity-specific address space identifies is indeterminate. The terms “entity-specific address” and “entity-specific identifier” are used interchangeably herein. An entity-specific address may identify an entity included in the entity to which the address is specific. Such as an address is said to be a “scoped”. An entity-specific address identifies an entity external to the entity to which the address is specific. Such as address is said to be “scope-specific”. The fact that an address is entity-specific does not define a scope for the address.
A portion of a network is a type of entity. A type of entity-specific address space described herein is a scope-specific address space. As used herein, a “scope-specific address space”, specific to a particular region of a network, is an address space defined for the particular network region, where an address in the scope-specific protocol address operates as an identifier, according to a network protocol, of a protocol endpoint in a node outside of the particular region when processed in the context of a node in the particular region. The region is indicated by the span of an indicated scope. The terms “region” and “zone” are used interchangeably herein. An address from a scope-specific address space is referred to herein as a “scope-specific protocol address”. An address is “scope-specific” in that what protocol endpoint it identifies depends on the region to which it is specific. Another address having the exact same form and content may identify a different protocol endpoint when in an address space that is specific to another region. A protocol address in a scope-specific address space serves as an identifier in the context of a node in a region to which the scope-specific address space is “specific” as defined by an association of the address space and the region indicated by the scope. Without knowledge of the particular region to which a scope-specific address space is specific, what a scope-specific protocol address in the scope-specific address space identifies is indeterminate. The terms “scope-specific protocol address” and “scope-specific protocol identifier” are used interchangeably herein. Types of scope-specific address spaces indicating exemplary spans include site-specific, LAN-specific, subnet-specific, city-specific, business-specific, and node-specific.
For a network protocol, an address in a scope-specific address space serves as an identifier of a protocol endpoint in a node. Data may be received via the protocol endpoint from a network via one or more network interfaces that operatively couple the node to the network. Data may be sent via the protocol endpoint to transmit over the network via the one or more network interfaces in the node. Since a protocol endpoint of a network protocol is included in a node and is accessible via a network via a network interface, a protocol address identifying the protocol endpoint also identifies the node and identifies a network interface of the node.
As used herein, a “node-specific address space” is a scope-specific address space defined for a specific node in a network, where the addresses in the node-specific address space operate as identifiers of nodes and/or network interfaces in the network when processed in the context of the specific node. An address from a node-specific address space is referred to herein as a “node-specific address”. An address is “node-specific” in that what it identifies depends on the node to which is defined as specific. Another address having the exact same form and/or content may identify a different node when in an address space specific to another node. Addresses in a node-specific address space operate as identifiers in the context of a node to which they are “specific” as defined by the specific association of the address space and the node. Without knowledge of the node to which a node-specific address space is specific, addresses in the node-specific address space are indeterminate. The terms “node-specific address” and “node-specific identifier” are used interchangeably herein. A node-specific address space is a type of scope-specific address space.
The term “node” is defined above. Note that an identifier of a network interface in a network also identifies a node that includes the network interface. Thus, a network interface-specific address is also a node-specific address. Network interfaces in a node may have their own respective network interface-specific address spaces that are also node-specific. The network interface-specific address spaces may be combined to form a node-specific address space and/or may be managed as separate address spaces. The adjectives “node-specific” and “network interface-specific” may be used interchangeably.
A scope-specific identifier differs from a scoped address. Scoped addresses are described in RFC 4007, RFC 3513, and further described in application Ser. No. 11/962,285, by the present inventor, filed on 2007 Dec. 21, entitled “Methods and Systems for Sending Information to a Zone Included in an Internet Network”. A scoped address space is shared by nodes in a given scope. While a link-local scoped address is specific to a particular node, a link-local scoped address simply identifies a network interface component local to the particular node. A loop-back internet address is specific to a node as well. Neither link-local scoped addresses nor loop-back addresses identify one node to another. As such, neither serves as a node-specific identifier as defined above.
A “scoped address” is described by RFC 3513 and RFC 4007 as an identifier that, in a particular region of a network, serves as a protocol address of a network interface and/or a node in the particular region. The extent of the particular region is referred to as the scope of the region and thus the scope within which the identifier serves as a protocol address. A particular region included within a scope is indicated by its span. A scoped address is a valid protocol address only within a particular region as indicated by the address's indicated scope. Examples of scope indicators include node-scope where identifiers are valid only to a single node in the indicated span, LAN-scope where identifiers are valid for nodes in the span of a particular LAN, and subnet-scope where identifiers are valid only for nodes in a particular subnet. RFC 3513 currently defines support for link-local scope, site-local scope, and global scope. A data unit transmitted with a scoped address should not be delivered to node that does not have a network interface in the span indicated by the scope.
“Path information” is any information that identifies a network path, such as a hop path, for data transmitted via one or more specified network protocols. Path information may be identified by identifying network interfaces, NICs, nodes, and/or hops included in a network path.
“Address information” is any information that identifies a protocol address that, for a network protocol, identifies a protocol endpoint. Address information may identify a unicast protocol address for a network protocol. In identifying a protocol endpoint, a protocol address identifies a node and a network interface.
For ease of illustration, the description that follows focuses on IP networks and protocols in the TCP/IP suite due to their wide use and because they are well-known in the art. Those skilled in the art will understand upon reading the descriptions herein that the subject matter disclosed herein is not restricted to the network protocols described and/or their corresponding OSI layers. For example, link layer protocols and link-layer networks are considered to be within the scope of the subject matter of this disclosure.
The term “metric space”, as used herein, refers to a set, as defined in mathematics, where a distance between elements of the set is defined according to a metric. Metric spaces defined in Euclidean geometry are well-known examples. Those skilled in the art of metric spaces, such as Euclidian spaces, will appreciate that a one-to-one mapping may be determined and/or otherwise identified for mapping addresses from a first coordinate space having a first origin for a metric space to addresses from a second coordinate space having a second origin in the metric space. Given a mapping rule between a first scope-specific address space and a second scope-specific address space and a mapping between the second scope-specific address space and a third scope-specific address space based on a third coordinate space identifying a third origin in the metric space, a mapping from the first coordinate space to the third coordinate space may be determined. A mapping between coordinate spaces for a metric space may include, for example, coordinate shift and/or a rotation. The mapping may be pre-specified and accessible to the nodes in one or both address spaces. Mapping between locations in a number of different metric spaces is well known in mathematics. For example, a top half of the surface of sphere may be mapped to a plane. Some will further appreciate that some metric spaces may be mapped to other metric spaces. Some of these mappings are one-to-one and/or on-to.
An “execution environment”, as used herein, is an arrangement of hardware and, in some aspects, software that may be further modified, transformed, and/or otherwise configured to include and/or otherwise host an arrangement of components to perform a method of the subject matter described herein. An execution environment includes a processor to execute an instruction included in at least one component of such an arrangement. An execution environment includes and/or is otherwise provided by one or more devices. The execution environment is said to be the execution environment “of” the device and/or devices. Exemplary devices included in and/or otherwise providing suitable execution environments that may be adapted, programmed, and/or otherwise modified according to the subject matter include a workstation, a desktop computer, a laptop or notebook computer, a server, a handheld computer, a mobile telephone or other portable telecommunication device, a media playing device, a gaming system, a tablet computer, a portable electronic device, a handheld electronic device, a multiprocessor device, a distributed system, a consumer electronic device, a router, a switch, a bridge, a network server, or any other type and/or form of computing, telecommunications, network, and/or media device that is suitable to perform the subject matter described herein. Those skilled in the art will understand that the components illustrated in
As used herein a “processor” is an instruction execution machine, apparatus, or device. A processor may include one or more electrical, optical, and/or mechanical components that operate in interpreting and executing program instructions. Exemplary processors include one or more microprocessors, digital signal processors (DSPs), graphics processing units, application-specific integrated circuits (ASICs), optical or photonic processors, and/or field programmable gate arrays (FPGAs).
The terms “network node” and “node” in this document both refer to a device having a network interface component capable of operatively coupling the device to a network. Further, the terms “device” and “node” used herein refer to one or more devices and nodes, respectively, providing and/or otherwise included in an execution environment unless clearly indicated otherwise.
As used herein, the term “network protocol” refers to a set of rules, conventions, and/or schemas that govern how nodes exchange information over a network. The set may define, for example, a convention and/or a data structure. For example, data for transmitting from a source node to a destination node may be included in a payload portion of a data unit of a particular network protocol. The network protocol may define a format that identifies the payload based on one or more valid data structures for a data unit. For example, a payload portion may be identified by a location with respect to the start of a data unit or relative to another portion of the data unit. Alternatively or additionally, the network protocol may be specified at least in part by a vocabulary defining a keyword, a bit pattern, and/or other detectable marker that when detected identifies a payload or part of a payload in a data unit. The network protocol may define one or more format rules and/or vocabulary rules that a data-in component may detect in identifying in a data unit an address field that includes and/or otherwise identifies a protocol address. The term “schema” refers to a definition of a structure and/or a vocabulary for constructing and/or detecting a valid data unit with respect to a network protocol for which the schema is defined. For example, both an IPv4 packet and an IPv6 packet are specified according to a schema that specifies rules for including a protocol address in a destination protocol address field and in a source protocol address field in an IP header based on location and size.
A “data unit”, as the term is used herein, is an entity specified according to a network protocol to transmit data between a pair of nodes in a network path in sending the data from a source node to a destination node that includes an identified protocol endpoint of the network protocol. A network protocol explicitly and/or implicitly specifies and/or otherwise identifies a schema that defines one or more of a rule for a format for a valid data unit and a vocabulary for content of a valid data unit. One example of a data unit is an Internet Protocol (IP) packet. The Internet Protocol defines rules for formatting an IP packet that defines a header to identify a destination address that identifies a destination node and a payload portion to include a representation of data to be delivered to the identified destination node. Various address types are specified defining a vocabulary for one or more address portions of an IP data unit. The terms “data unit”, “frame”, “data unit”, and “packet” are used interchangeably herein. One or more data units of a first network protocol may transmit a “message” of a second network protocol. For example, one or more data units of the IP protocol may include a TCP message. In another example, one or more TCP data units may transmit a HTTP message. A message may be empty.
How data is packaged in one more data units for a network protocol may vary as the data traverses a network path from a source node to a destination node. Data may be transmitted in a single data unit between two consecutive nodes in a network path. Additionally, data may be exchanged between a pair of consecutive nodes in several data units each including a portion of the data. Data received in a single data unit by a node in a network path may be split into portions included in several respective data units to transmit to a next node in the network path. Portions of data received in several data units may be combined into a single data unit to transmit by a node in a network path. For purposes of describing the subject matter, a data unit in which data is received by a node is referred to as a different data unit than a data unit in which the data is forwarded by the node.
A “protocol address”, as the term is used herein, for a network protocol is an identifier of a protocol endpoint of the network protocol. The protocol address may be represented in a data unit of the network protocol. For example, “192.168.1.1” is an IP protocol address represented in a human readable format that may be represented in an address portion of an IP header to identify a source and/or a destination IP protocol endpoint. A protocol address differs from a symbolic identifier, defined below, in that a symbolic identifier, with respect to a network protocol, maps to a protocol address. Thus, “www.mynode.com” may be a symbolic identifier for a node in a network when mapped to the protocol address “192.168.1.1”. An identifier may be both a symbolic identifier and a protocol address depending on its role with respect to its use for a particular network protocol.
Since a protocol endpoint is accessible by way of a network via a network interface in a node, a protocol address identifies a node and identifies a network interface of the node. A network interface may include one or more NICs operatively coupled to a network.
A node in a pair of nodes in a network path at one end of the sequence of nodes in the network path and/or the other end is referred to herein as a “path end node”. Note that a node may have two NICs with one NIC at each end of a network path. A network path may be included as a portion of another network path that communicatively couples a same pair of nodes. Data may be transmitted via the sequence of nodes in a network path between path end nodes communicatively coupled via the network path. Data may be transmitted in one or both directions depending on an ordering of the nodes in the sequence.
The term “network path” as used herein refers to a sequence of nodes in a network that are communicatively coupled to transmit data in one or more data units of a network protocol between a pair of nodes in the network.
The term “hop” as used herein refers to a pair of consecutive nodes in a network path to transmit, via a network protocol, data sent from a source node to a destination node. A “hop path” is thus a sequence of hops in a network that respectively include a sequence of pairs of consecutive nodes included in transmitting data from a first path end node of the network path to a second path end node of the network path. A “network path” is thus a sequence of hops in a network that respectively includes a sequence of pairs of consecutive network interfaces included in transmitting data from a first path end node of the network path to a second path end node of the network path.
Given the above definitions, note that the terms “network path” and “hop” may be defined in terms of network interfaces. A “network path” is a sequence of network interfaces in a network to transmit data in one or more data units of a specified network protocol between a pair of path end nodes in the network. A “hop” refers to a pair of consecutive network interfaces, in a pair of nodes, in a sequence of network interfaces in a network path. A hop in a sequence in a network path corresponds to a pair of network interfaces in the sequence of network interfaces in the network path.
The term “path-based protocol address” as used herein refers to a protocol address for a network protocol that includes one or more path segment identifiers that identify one or more respective portions of a network path identified by the path-based protocol address. A “node-based protocol address” is a path-based protocol address that includes a plurality of node identifiers that identify a sequence of nodes in a network path. A “network-interface-based protocol address” is a path-based protocol address that includes a plurality of network interface identifiers that identify a sequence of network interfaces in a network path. A “NIC-based protocol address” is a type of network-interface-based protocol address that includes a plurality of identifiers that identify a sequence of network interface components. A “hop-based protocol address” is a type path-based protocol address since a hop is a type of network path. The protocol address types defined are not mutually exclusive.
The term “network topology” or “topology”, for short, as used herein refers to a representation of protocol endpoints, network interfaces, and/or nodes in a network, and representations of communicative couplings between and/or among the protocol endpoints, network interfaces, and/or nodes in the network. A network may have different network topologies with respect to different network protocols and/or address spaces. A network topology may represent physical communicative couplings between protocol endpoints, network interfaces, and/or nodes in the network. A network topology may represent logical couplings between protocol endpoints, network interfaces, and/or nodes of a particular network protocol or a particular type of network protocol.
The domain name system (DNS) of the Internet operates based on an application layer protocol defined by the DNS. The nodes in the DNS are communicatively coupled via the DNS protocol and may be represented by a logical network topology. A DNS system includes nodes connected via the DNS protocol. The DNS system has a network topology defined by nodes that include protocol endpoints of the DNS protocol. Such a topology may also include nodes that relay DNS protocol data units between and/or among nodes with DNS protocol endpoints. In still another example, a token-ring network has a circular topology at the link layer, but may have a star topology at the physical layer.
As used herein, an “entity-specific address space” refers to an address space defined for a specific entity where the addresses in the address space operate as identifiers in the context of the entity. An address from an entity-specific address space is referred to herein as an “entity-specific address”. An address is “entity-specific” in that what it identifies is based on the entity to which it is specific. An address may identify one entity in one address space specific to a particular entity and may identify a different entity in another address space specific to a different entity. Addresses in an entity-specific address space operate as identifiers in the context of an entity to which they are “specific” as defined by the specific association of the address space and the entity. Without knowledge of the entity to which an entity-specific address space is specific, what an address in the entity-specific address space identifies is indeterminate. The terms “entity-specific address” and “entity-specific identifier” are used interchangeably herein. An entity-specific address may identify an entity included in the entity to which the address is specific. Such as an address is said to be a “scoped”. An entity-specific address identifies an entity external to the entity to which the address is specific. Such as address is said to be “scope-specific”. The fact that an address is entity-specific does not define a scope for the address.
A portion of a network is a type of entity. A type of entity-specific address space described herein is a scope-specific address space. As used herein, a “scope-specific address space”, specific to a particular region of a network, is an address space defined for the particular network region, where an address in the scope-specific protocol address operates as an identifier, according to a network protocol. of a protocol endpoint in a node outside of the particular region when processed in the context of a node in the particular region. The region is indicated by the span of an indicated scope. The terms “region” and “zone” are used interchangeably herein. An address from a scope-specific address space is referred to herein as a “scope-specific protocol address”. An address is “scope-specific” in that what protocol endpoint it identifies depends on the region to which it is specific. Another address having the exact same form and content may identify a different protocol endpoint when in an address space that is specific to another region. A protocol address in a scope-specific address space serves as an identifier in the context of a node in a region to which the scope-specific address space is “specific” as defined by an association of the address space and the region indicated by the scope. Without knowledge of the particular region to which a scope-specific address space is specific, what a scope-specific protocol address in the scope-specific address space identifies is indeterminate. The terms “scope-specific protocol address” and “scope-specific protocol identifier” are used interchangeably herein. Types of scope-specific address spaces indicating exemplary spans include site-specific, LAN-specific, subnet-specific, city-specific, business-specific, and node-specific.
For a network protocol, an address in a scope-specific address space serves as an identifier of a protocol endpoint in a node. Data may be received via the protocol endpoint from a network via one or more network interfaces that operatively couple the node to the network. Data may be sent via the protocol endpoint to transmit over the network via the one or more network interfaces in the node. Since a protocol endpoint of a network protocol is included in a node and is accessible via a network via a network interface, a protocol address identifying the protocol endpoint also identifies the node and identifies a network interface of the node.
As used herein, a “node-specific address space” is a scope-specific address space defined for a specific node in a network, where the addresses in the node-specific address space operate as identifiers of nodes and/or network interfaces in the network when processed in the context of the specific node. An address from a node-specific address space is referred to herein as a “node-specific address”. An address is “node-specific” in that what it identifies depends on the node to which is defined as specific. Another address having the exact same form and/or content may identify a different node when in an address space specific to another node. Addresses in a node-specific address space operate as identifiers in the context of a node to which they are “specific” as defined by the specific association of the address space and the node. Without knowledge of the node to which a node-specific address space is specific, addresses in the node-specific address space are indeterminate. The terms “node-specific address” and “node-specific identifier” are used interchangeably herein. A node-specific address space is a type of scope-specific address space.
The term “node” is defined above. Note that an identifier of a network interface in a network also identifies a node that includes the network interface. Thus, a network interface-specific address is also a node-specific address. Network interfaces in a node may have their own respective network interface-specific address spaces that are also node-specific. The network interface-specific address spaces may be combined to form a node-specific address space and/or may be managed as separate address spaces. The adjectives “node-specific” and “network interface-specific” may be used interchangeably.
A scope-specific identifier differs from a scoped address. Scoped addresses are described in RFC 4007, RFC 3513, and further described in application Ser. No. 11/962,285, by the present inventor, filed on 2007 Dec. 21, entitled “Methods and Systems for Sending Information to a Zone Included in an Internet Network”. A scoped address space is shared by nodes in a given scope. While a link-local scoped address is specific to a particular node, a link-local scoped address simply identifies a network interface component local to the particular node. A loop-back internet address is specific to a node as well. Neither link-local scoped addresses nor loop-back addresses identify one node to another. As such, neither serves as a node-specific identifier as defined above.
A “scoped address” is described by RFC 3513 and RFC 4007 as an identifier that, in a particular region of a network, serves as a protocol address of a network interface and/or a node in the particular region. The extent of the particular region is referred to as the scope of the region and thus the scope within which the identifier serves as a protocol address. A particular region included within a scope is indicated by its span. A scoped address is a valid protocol address only within a particular region as indicated by the address's indicated scope. Examples of scope indicators include node-scope where identifiers are valid only to a single node in the indicated span, LAN-scope where identifiers are valid for nodes in the span of a particular LAN, and subnet-scope where identifiers are valid only for nodes in a particular subnet. RFC 3513 currently defines support for link-local scope, site-local scope, and global scope. A data unit transmitted with a scoped address should not be delivered to node that does not have a network interface in the span indicated by the scope.
“Path information” is any information that identifies a network path, such as a hop path, for data transmitted via one or more specified network protocols. Path information may be identified by identifying network interfaces, NICs, nodes, and/or hops included in a network path.
For ease of illustration, the description that follows focuses on IP networks and protocols in the TCP/IP suite due to their wide use and because they are well-known in the art. Those skilled in the art will understand upon reading the descriptions herein that the subject matter disclosed herein is not restricted to the network protocols described and/or their corresponding OSI layers. For example, link layer protocols and link-layer networks are considered to be within the scope of the subject matter of this disclosure.
The term “metric space”, as used herein, refers to a set, as defined in mathematics, where a distance between elements of the set is defined according to a metric. Metric spaces defined in Euclidean geometry are well-known examples. Those skilled in the art of metric spaces, such as Euclidian spaces, will appreciate that a one-to-one mapping may be determined and/or otherwise identified for mapping addresses from a first coordinate space having a first origin for a metric space to addresses from a second coordinate space having a second origin in the metric space. Given a mapping rule between a first scope-specific address space and a second scope-specific address space and a mapping between the second scope-specific address space and a third scope-specific address space based on a third coordinate space identifying a third origin in the metric space, a mapping from the first coordinate space to the third coordinate space may be determined. A mapping between coordinate spaces for a metric space may include, for example, coordinate shift and/or a rotation. The mapping may be pre-specified and accessible to the nodes in one or both address spaces. Mapping between locations in a number of different metric spaces is well known in mathematics. For example, a top half of the surface of sphere may be mapped to a plane. Some will further appreciate that some metric spaces may be mapped to other metric spaces. Some of these mappings are one-to-one and/or on-to.
A “source-route protocol address”, as the term is used herein, is a protocol address of a network protocol that identifies a protocol endpoint in a second node for a first node, and that also includes or otherwise identifies at least one path node that communicatively couples the first node and the second node. A node identified by a source-route protocol address may be identified by a network interface identifier of a network interface in the path node, by a hop that includes the path node, and by a protocol address that for a network protocol identifies the path node to another node in a network path that communicatively couples the first node and the second node.
Execution Environment:
An exemplary device included in an execution environment that may be programmed, adapted, modified, and/or otherwise configured according to the subject matter is illustrated in
Processor 10104 may access instructions and data via one or more memory address spaces in addition to the physical memory address space. A memory address space includes addresses identifying locations in a processor memory. The addresses in a memory address space are included in defining a processor memory. Processor 10104 may have more than one processor memory. Thus, processor 10104 may have more than one memory address space. Processor 10104 may access a location in a processor memory by processing an address identifying the location. The processed address may be identified by an operand of an instruction and/or may be identified by a register and/or other portion of processor 10104.
Physical processor memory 10106 may include various types of memory technologies. Exemplary memory technologies include static random access memory (SRAM), Burst SRAM or SynchBurst SRAM (BSRAM), Dynamic random access memory (DRAM), Fast Page Mode DRAM (FPM DRAM), Enhanced DRAM (EDRAM), Extended Data Output RAM (EDO RAM), Extended Data Output DRAM (EDO DRAM), Burst Extended Data Output DRAM (BEDO DRAM), Enhanced DRAM (EDRAM), synchronous DRAM (SDRAM), JEDEC SRAM, PC 10100 SDRAM, Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), SyncLink DRAM (SLDRAM), Ferroelectric RAM (FRAM), RAMBUS DRAM (RDRAM) Direct DRAM (DRDRAM), and/or XDRTM DRAM. Physical processor memory 10106 may include volatile memory as illustrated in the previous sentence and/or may include non-volatile memory such as non-volatile flash RAM (NVRAM) and/or ROM.
Persistent secondary storage 10108 may include one or more flash memory storage devices, one or more hard disk drives, one or more magnetic disk drives, and/or one or more optical disk drives. Persistent secondary storage may include a removable data storage medium. The drives and their associated computer readable media provide volatile and/or nonvolatile storage for computer-executable instructions, data structures, software components, and other data.
Execution environment 10102 may include software components stored in persistent secondary storage 10108, in remote storage accessible via a network, and/or in a processor memory.
Execution environment 10102 may receive user-provided information via one or more input devices illustrated by an input device 10128. Input device 10128 provides input information to other components in execution environment 10102 via input device adapter 10110. Execution environment 10102 may include an input device adapter for a keyboard, a touch screen, a microphone, a joystick, a television receiver, a video camera, a still camera, a document scanner, a fax, a phone, a modem, a network interface adapter, and/or a pointing device, to name a few exemplary input devices.
Input device 10128 included in execution environment 10102 may be included in device 10100 as
An output device 10130 in
A device included in and/or otherwise providing an execution environment may operate in a networked environment communicating with one or more devices via one or more network interface components.
Some components, illustrated in the drawings are identified by numbers with an alphanumeric suffix. A component may be referred to generically in the singular or the plural by dropping a suffix of a portion thereof of the component's identifier. For example, nodes; such as node 10502a1, node 10502a2, node 10502a3, and their adaptations and analogs; are referred to herein generically with respect to
Some or all of the exemplary components illustrated in
An application, such as a networking application 10403 operating in a node 10502, may exchange data with another node 10502 by interoperating with one or more components of a corresponding network stack 10405. In
Transport layer protocols supported by connectionless component 10409 and by connection-oriented component 10411 generate transport layer data units to include data received from an operatively coupled application to deliver the data via the data units according to a network layer protocol to a transport layer protocol endpoint, such as a socket, in another node 10502. Analogously, data sent via an application in another node via a transport layer component may be received according to the network layer protocol by a compatible transport layer component, such as a connection-oriented component 10411 and/or by a connectionless component 10409, to deliver via a socket to an application operating in the execution environment 10401 in the receiving other node 10502.
A network layer protocol is designed and configured to deliver data across one or more communication links and/or networks between nodes in a network or internet. In
One or more link layer protocols may be included in communicatively coupling a source node 10502 and a destination node 10502 via a network path that includes one or more path nodes 10504 as illustrated in
For ease of illustration, the description that follows focuses on IP networks and protocols in the TCP/IP suite due to their wide use and because they are well-known in the art. Those skilled in the art will understand that the scope of the subject matter described is not limited to IP networks. For example, link layer protocols and networks are considered to be within the scope of the subject matter of this disclosure.
With respect to
A network layer component 10413 operating in a node 10502 may communicate with one or more nodes 10502 over a LAN, a link, and/or a network of networks such as an intranet or the Internet. A network layer component 10413 in the node 10502 may receive transport layer data units, for example, formatted as TCP packets from a connection-oriented layer component 10411 and/or transport layer data units formatted as UDP packets from a connectionless component 10409 illustrated in
Analogously, the network layer component 10413 interprets data, received from a link layer component 10415 in the node 10502b, as IP protocol data and detects IP packets in the received data. The network layer component 10413 may strip off IP layer specific data and transfer the payload of one or more IP packets to the connection-oriented layer component 10411 and/or to the connectionless component 10409 to process as transport layer data units according to a particular transport layer protocol.
As described above,
In addition to the protocols described above, protocols corresponding to layers in the OSI model above the transport layer may be included in communicating via a network. The term “application protocol” as used herein refers to any protocol or combination of protocols that correspond to one or more layers in the OSI reference model above the transport layer. Programs and executables operating in execution environments 10401 may communicate via one or more application protocols. Exemplary application protocols include a hypertext transfer protocol (HTTP), various remote procedure call (RPC) protocols, various instant messaging protocol, email protocols, and various presence protocols.
Data exchanged between nodes 10502 in a network 10500a may be exchanged via data units of one or more protocols. Each layer of a network stack may provide a layer specific protocol component. Some protocols, combine services from multiple layers of the OSI model into a single layer such as the Systems Network Architecture (SNA) protocol. Still others may take a hybrid approach. With the advent of software defined networking and flexible protocols such as OpenFlow, new protocols and variations of existing protocols are being introduced and will be introduced that are within the scope of the subject matter of the present disclosure.
A network protocol is defined by one or more formatting rules and/or a vocabulary referred to as a schema. The schema defines valid data units to exchange between and/or among protocol endpoints defined by the respective network protocol. A network protocol also specifies and/or otherwise is compatible with one or more address spaces for identifying protocol endpoints for exchanging data. The terms “identifier space” and “address space” are used interchangeably herein. For example, various versions of hypertext transfer protocol (HTTP) specify a format for HTTP uniform resource locators (URL). HTTP specifies a location in a HTTP header that identifies a URL as an identifier or address from the HTTP address space that identifies both a resource and recipient of a HTTP data unit. The transmission control protocol (TCP) specifies a format and vocabulary for a TCP header including a destination protocol endpoint field for including what the TCP refers to as a destination port number that, when combined with a destination protocol address from an IP packet, identifies a transport layer protocol endpoint of a receiver of data included in a TCP data unit. A sending endpoint is similarly identified by a source port number included in a source protocol endpoint field of a TCP data unit and a source protocol address from an IP data unit.
Other exemplary address spaces that identify protocol endpoints in various protocols include an email address space identifying a protocol endpoint for the simple mail transfer protocol (SMTP), a telephone number address space for various telephony protocols, instant message address spaces for various instant message protocols, and media access control (MAC) addresses for various link layer protocols, to name just a few examples.
In delivering data across a network between protocol endpoints, addresses from address spaces of the various protocols at the various layers may be translated and/or otherwise mapped between the various layers of a network stack. For example, a unicast IP address in an IP packet is mapped to link layer addresses for the various links the IP packet is transported across in a network path via a path node 10504 between a source node 10502 sending the IP packet and a destination node 10502 receiving the IP packet. Addresses at the various layers are assigned from a suitable address space of network protocols of the respective layers.
Since addresses from address spaces at various layers of a network stack are often not suited for remembering and/or identifying by users, an address space of symbolic identifiers or names may be used to provide aliases for addresses in an address space identifying protocol endpoints corresponding to a protocol supported by a layer of a network stack. The domain name space is a well-known identifier space of names for identifying nodes and/or network interfaces as protocol endpoints of the IP protocol in the Internet, private internets, and intranets. The domain name system (DNS) is a collection of domain name system services maintaining databases that associate names from the domain name space with protocol addresses, in particular with IP addresses. The domain name space defines a global name space shared across the Internet.
In
Aspects of Operation in Execution Environments
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
In
For example, the arrangement in
While the subject matter disclosed herein is applicable to network protocols at various layers, the present disclosure describes embodiments at layer 3 (i.e. the network layer) and layer 2 (i.e. the link layer) of the OSI stack. Examples of network layer protocols that may be modified to support various types of addresses described, such as scope-specific addresses, include an Internet Protocol (IP), DECNet outing Protocol (DRP), an Internetwork Packet Exchange (IPX) protocol, an Internet Datagram Protocol (IDP), a VINES Internet Protocol, and a Datagram Delivery Protocol (DDP).
Examples of link layer protocols that may be modified to support scope-specific addresses and/or other address types disclosed herein including variants and analogs include an Ethernet protocol, Token-ring protocol, FDDI protocol, and an asynchronous transfer mode (ATM) protocol.
A network protocol may be defined by a schema. The schema may define a data unit of the network protocol including a data portion, referred to herein as a payload portion, defined for including data to transmit between protocol endpoints of the network protocol. A protocol schema may specify a protocol address portion of a data unit defined to include a protocol address in an address space of the network protocol. A protocol address portion may be included in a data unit that identifies a destination node. A protocol address portion may be included in a data unit that identifies a source node. A protocol address portion in a data unit is not included in the payload portion of a data unit for the network protocol. The schema defines at least one rule and/or a vocabulary including one or more elements. The one or more rules and/or one or more elements in the vocabulary may define a constraint for including and/or otherwise identifying a protocol address in a data unit of the network protocol. Such a protocol address may identify, according to the schema, a destination protocol endpoint. A destination node that includes the destination protocol endpoint is identified as well.
Data to transmit in a payload portion may be received from an application process, such as application 10403, operating in an execution environment, such as execution environment 10401, of a source node such as various nodes 10502 in
A region having a scope-specific address space may include a network interface of a source node.
A region of a network having a scope-specific address that identifies one or more nodes not in the region may be defined by a span of a scoped address. Scoped addresses are described in RFC 3513 and in RFC 4007 included by reference in the present disclosure above. The nodes in the span may identify one another for the network protocol via scoped addresses. In the first region 10510a1 in
A protocol address that identifies a destination node may be identified in various ways, in various aspects. With respect to
A protocol address may be formatted as required by the network protocol and address space supported by the network layer component 10413. Schemas for scope-specific address spaces are illustrated in
The first node 10502a1 may identify the destination node by identifying a protocol endpoint, of the network protocol, that is in a node outside the first region 10510a1. As defined and described herein, such a protocol endpoint may be identified by a protocol address from a first scope-specific address space specific to the first region 10510a1. The protocol address identifies the node including the protocol endpoint and identifies a network interface of the node. With respect of
The address information may be detected by the address space component 10404. The address space component 10404 may include instructions that when executed by processor are included in generating and/or storing a representation of the first protocol address as address information in a data unit specified according to the network protocol, such as the Internet Protocol, supported by the network layer component 10413. The address space component 10404 may interoperate with a packet generator component 10423 to include the address information in the data unit as specified by the network protocol.
In
A packet generator component 10423 in an execution environment 10402 of the first node 10502a1 may include one or more instructions that when performed by the first node 10502a1 identifies a source protocol address based on address information represented in a data unit of a network protocol to identify the first node 10502a1 as the source node of the data in the data unit. The packet generator component 10423 may interoperate with the address space component 10404 to receive the source address information to include a representation of the source protocol address in the data unit.
An address space component 10404 in the first node 10502a1 may identify a source protocol address that, in a second scope-specific address space specific to the second region 10510a2 that includes the second node 10502a2, identifies the first node 10502a1. The second scope-specific address space may be node-specific. The sequence, 101.101.100.103, identifies a sequence of network interfaces in a network path from the second node 10502a2 to the first node 10502a1 that, in a second node-specific address space specific to the second node 10502a2, identifies the first node 10502a1. The source protocol address may be pre-specified to the first node 10502a1 via a user and/or may be determined based on a previous communication with the second node 10502a2. The source protocol address may be retrieved via a request to a network directory service, as described in more detail below.
In another aspect, a packet generator component 10423 may receive source address information that identifies a scoped address that identifies the first node 10502a1 in the first region 10510a1. In
A first node may detect address information that identifies a first-second protocol address that, in a first scope-specific address space specific to a first region that includes the first node, identifies the second node. Alternatively or additionally, the second node may detect address information that identifies a second-first protocol address that, in a second scope-specific address space specific to a second region that includes the second node, identifies the first node to the second node. Alternatively or additionally, the second node may receive address information identifying the first-second protocol address. The second node may determine the second-first protocol address based on the first-second protocol address. Alternatively or additionally, the first node may receive the second-first protocol address. The first node may determine the first-second protocol address based on the second-first protocol address.
Returning to
The packet detector component 10435 may detect an address representation in the data unit according to a schema defined by a network layer protocol supported by the network layer component 10413. The address information represented may be provided to an address space component 10404. An address space component 10404 operating in the third node 10502a3 may receive and/or otherwise detect the address information via a packet detector component 10435.
The address space component 10404 may determine an address space that includes a protocol address identified by the address information. For example, the address space component 10404 may identify that a protocol address detected in the address information is in a third scope-specific address space specific to a third region 10510a3 that includes the third node 10502a3 in detecting an identifier of a node, such as the second node 10502a2, that sent the data in the received data unit.
When the protocol address, identified in address information is detected by the address space component 10404, is not in an address space that is usable for sending data to another node, the address space component 10404 may determine a protocol address in a suitable address space as described in more detail below. The address space component 10404 may receive address information that identifies the third node, in a second scope-specific address space of the second node that sent the data unit. The address space component 10404 may determine a third-second protocol address that, in a third node-specific address space specific to the third node, identifies the second node 10502a2. In another aspect, the address information may identify a global or local scoped address. The data in the data unit may be provided by the network layer component 10413 to a protocol endpoint identified by a higher layer protocol as described above.
A scope-specific address may be formatted to be included in data units of an existing network protocol. For example, a schema for a scope-specific address space may be defined to include an address in the address space in an address field of a header of the IP protocol according to a currently existing specification, such as RFC 791 and/or RFC 3513. While such protocol addresses may have the same or substantially similar rules for valid format and content as those currently in use, the protocol addresses when processed according to the subject matter described herein are scope-specific and identify nodes in the context of regions to which they are specific. For details on the format and vocabularies of current address spaces refer to the appropriate specification. A type bit and/or a pattern of bits in a data unit header may be defined by a network protocol to indicate that address information in the data unit identifies a scope-specific address.
With respect to
At the first node 10502a1, a packet generator component 10423 and/or an address space component 10404 operating in the first node 10502a1 may set and/or otherwise detect a value in the address separator field 10604a that indicates a first address field 10608a has a zero size. The entire address information field 10606a, thus, constitutes a second address field 10610a at the first node 10502a1 and identifies the first-second protocol address that may be set and/or otherwise detected by the path separator component 10437.
At a third path node 10504a3, an address separator field 10604a in a data unit including the data from the first node 10502a1 may be set to and/or otherwise may be detected, by a path separator component 10437 and/or an address space component 10404 in the third path node 10504a3, as a value that identifies 102.102, in a first address field 10608a. The information in the first address field 10608a identifies a protocol address that, in the first scope-specific address space identifies the third path node 10504a3. The value in the address separator field also identifies a second address field 10610a that identifies 103.103 as a protocol address that, in a fifth scope-specific address space specific to a fifth region 10510a5 including the third path node 10504a3, identifies the second node 10502a2.
At the second node 10502a2 a data unit including the data from the first node 10502a1 may include a value, set and/or detected by a path separator component in the second node 10502a2, in an address separator field 10604a that indicates that the address information field 10606a includes only a first address field 10608a identifying 102.102.103.103 as the first protocol address.
As the data from the first node 10502a1 is transmitted from node to node in the network path the value represented in an address separator field 10604a in an address information field 10606a in a data unit including the data or a portion thereof may be adjusted by respective path separator components 10437 in the nodes in the network path to identify a protocol address in a suitable address space for the respective nodes.
At the second node 10502a2, the value in the separator address field may indicate to an address space component 10404 that address information field 10606a also includes information for determining and/or otherwise identifying a second-first protocol address that, in the second scope-specific address space, identifies the first node 10502a1. An example and description are provided below.
The above describes an address representation 10602a processed to identify destination address information in a data unit of a network protocol, such as an IP protocol and/or a layer 2 protocol. An address representation 10602a may include source address information with respect to a node receiving data in a data unit, described in the previous paragraph, sent from the first node 10502a1 to the second node 10502a2. An address information field 10606a including source address information at the third path node 10504a3 may include a first address field 10608a identifying the sequence, 100.103, that identifies a protocol address that, in the fifth scope-specific address space specific to the fifth region 10510a5, identifies the first node 10502a1 as the source node for the data in the data unit. The address information field 10606a including the source address information at the third path node 10504a3 may include a second address field 10610a identifying the sequence 101.101 that identifies a protocol address that, in the second node-specific address space specific to the second region 10510a2, identifies the third path node 10504a3 as a path node in the network path traversed by the data sent from the first node 10502a1.
A destination-source protocol address, that in a destination scope-specific address space specific to a destination network region that includes the destination node, identifies the source node may be identified. A data unit may include separate address representations for destination address information and source address information as, for example, current IP packet headers are specified. Alternatively, a data unit such as an IP packet and or an Ethernet frame may include an address representation that identifies source address information in the context of one address space specific to a node, in a region, in a network path traversed by the data unit and identifies destination address information to another node, in another region in the network path.
A source-destination protocol address may identify a destination-source protocol address. Rather than requiring separate source and destination representations as current packet headers require, such as IP packets, a single address representation may identify some or all of a destination protocol address with respect to one scope-specific address space and some or all of a source protocol address with respect to another scope-specific address space. More details, as well as examples, are described below.
In
A first node 10502c1 may identify a second node 10502c2 by a first-second protocol address that, in a first scope-specific address space specific to a first region 10510c1 including the first node 10502c1, identifies the second node 10502c2. The first-second protocol address may include and/or otherwise may be based on a sequence of hop identifiers 100.100.101.103.102.101. Note that other network paths are illustrated for transmitting data from the first node 10502c1 to the second node 10502c2 and may also be and/or otherwise may identify protocol addresses in the first scope-specific address space that identify the second node 10502c2 to nodes in the first region 10510c1. Note that the second path node 10504c2 includes a network interface that is in the first region 10510c1 and a network interface that is not in the first region. In communicating with the second node 10502c2, via the network interface outside the first region 10510c1, the second path node 10504c2 is defined to be outside the first region 10510c1. When the second path node 10504c2 communicates with a node outside the first region 10510c1 via the second path node's 10504c2 network interface in the first region 10510c1, the second path node 10504c2 is defined to be in the first region 10510c1. For example when the second path node 10504c2 communicates with a twelfth node 1050210c12 via fourth node 10502c4, the second path 10504c2 is in the first region 10510c2 with respect to the twelfth node 1050210c12.
The second node 10502c2 may identify a third node 10502c3 by a second-third protocol address that, in a second node-specific address space specific to the second node 10502c2 in the second region 10510c2, identifies the third node 10502c3. The protocol address may be based on a sequence of hop identifiers 101.103.100 that identifies the third node 10502c3 with respect to the second node 10502c2. The third node 10502c3 is in a third region 10510c3. Within the third region 10510c3, the third node 10502c3 may be identified by a local-scope address 100. Nodes in the third region 10510c3 may identify nodes outside the third region 10510c3 with identifiers from a third scope-specific address space specific to the third region 10510c3.
The hop identifiers, 100.101.103.102.101, may be represented in an address representation 10602c in a data unit for sending data from the first node 10502c1 to the second node 10502c2. The hop identifiers, 101.103.100, may be represented in an address representation 10602c in a data unit for sending data from the second node 10502c2 to the third node 10502c3. The identifiers may be given a bit or binary representation and the hop identifiers may be distinguished or separated via address separator fields 10604c as described above with respect to
Note that the address information that identifies protocol addresses for the second node 10502c2 and for the third node 10502c3 in the preceding description may include information for identifying a return path or a portion thereof. For example, the second-third protocol address 101.103.100 identifies 103.101, which may be a portion of a third-second protocol address that, in the third scope-specific address space, identifies the second node 10502c2 for nodes in the third region 10510c3. The first-second protocol address, 100.101.103.102.101, identifies 101.102.103.101 that, in the second-node-specific address space, identifies a network path from the second node to the first region 10510c1. Note that the second node may be in a region that includes only one node. The sequence, 101.102.103.101, however, does not identify any network interfaces of nodes in the first region 10510c1. Separate source address information may be included in a data unit sent to the second node 10502c2 that includes data sent from the first node 10502c1. The source address information may identify 101.102.103.101.10101 as a second-first protocol address that, in the second node-specific address space, identifies the first node 10502c2. In, the first region 10510c1, 10101 may be a scoped address that identifies the first node 10502c1 in the scope of the first region 10510c1. Thus, a scope-specific address may include a scoped address.
As described in the previous paragraph, a hop may be assigned an identifier that is shared by the pair of nodes in the hop. Thus, a sequence of hop identifiers may serve as a scope-specific address in one scope-specific address space when processed in one order of the sequence and may serve as another scope-specific address specific to another node when processed according to another order of the sequence. Any of the address types illustrated in
An address separator field 10604d includes series of 1-valued bits and 0-valued bits. A change from a 1 value to a 0 value and vice versa may indicate a boundary that separates protocol endpoint identifiers and/or interface identifiers. An address separator field 10604d1 includes one 0-valued bit followed by four 1-valued bits. The 0-valued bit may be defined to indicate that a first network interface in a first hop identifier is 1 bit long with a corresponding position in the address information field 10606d.
Note that the address separator field 10604d6 does not identify a pair of identifiers and is similar to address separator fields 10604c in
In
Note that reversing the interface identifiers yields the identifier 1010-10151.10254-10151 that may be a protocol address that, in a second node-specific address space specific to the second node 10502b2, identifies the first node 10502b1. The second node 10502b2 and a third node 10502b3 may be included in regions that respectively include the nodes. Each of the two nodes may identify the other by a protocol address in a respective node-specific address space. A sequence of pairs of interface identifiers 1010-10254.10151-1010 may be a protocol address that, in the second node-specific address space, identifies the third node 10502b3. Reversing the interface identifiers yields the identifier 1010-10151.10254-1010 that may be a protocol address that, in a third node-specific address space specific to the third node 10502b3, identifies the second node 10502b2.
A sequence of hop identifiers based on interface identifiers may serve as a scope-specific address in one scope-specific address space when processed in one order of the sequence and may serve as another scope-specific address specific to another node when processed according to another order of the sequence.
See application Ser. No. 11/962,285, by the present inventor, filed on 2007 Dec. 21, entitled “Methods and Systems for Sending Information to a Zone Included in an Internet Network” for a description of addresses having outside scope and/or inside scope and processing of such addresses. A third address information field 10606e3 corresponding to a third address separator field 10604e3 may include a pair of identifiers as described with respect to
In
As described above, a source-destination protocol address may include and/or may otherwise identify source-destination path information identifying a source-destination network path included in communicatively coupling the source node and the destination node. A source-destination protocol address may include and/or may otherwise identify first hop information identifying a first hop including a first pair of communicatively coupled nodes included in communicatively coupling the source node and the destination node. At least one the hop identifier may include and/or may otherwise identify an identifier of at least one of the nodes in the first pair. The identifier of the at least one of the nodes in the first pair may include and/or otherwise may identify a network interface that is included in communicatively coupling the first pair. A source-destination protocol address may include and/or may otherwise identify a plurality of hop identifiers in an identifiable first order and in an identifiable second order, wherein the source-destination protocol address includes the plurality of hop identifiers in the first order and a destination-source protocol address, that identifies the source node to the destination node, includes the plurality of hop identifiers in the second order. At least one of the first order and the second order may be identified in the data unit by sequence information defined by a schema of the network protocol. The sequence information may be represented separately from the plurality of hop identifiers
One or more network layer protocol data units may be provided to a link layer component 10415 as data to include in one or more link layer protocol data units to transmit via a NIC 10417 based on the network interface identified by the packet generator component 10423. In a node with one NIC operatively coupled to a physical data transmission medium or with multiple NICs operatively coupled to the shared data transmission medium, an endpoint-out component 10406 may send network layer data packets via the one NIC or any of the multiple NICs over the physical data transmission medium to deliver to the destination node according to a network interface identified by the packet generator component 10423. Link layer protocol data units may be sent by the link layer component 10415 according to a compatible link layer protocol and link layer address information. For example, Ethernet frames may be sent as link layer protocol data units via an Ethernet cable operatively coupled to a NIC 10417 included in a suitable network path to transmit the data to the destination node.
Additionally, the source-destination protocol address and/or the destination-source protocol address may include a plurality of hop identifiers identifying a sequence of hopes in a network path included in communicatively coupling the source node and the destination node. The address information may include the plurality of hop identifiers in an identifiable first order and in an identifiable second order. The source-destination protocol address may include the plurality of hop identifiers in the first order. The destination-source protocol address may include the plurality of hop identifiers in the second order. One or both of the first order and the second may be identified in the address information. One or both of the first order and the second order may be identified by sequence information represented separately from the plurality of hop identifiers.
A first hop including a first hop node and a second hop node, both in the network path, may be identified with respect to the source node by a source hop identifier in a source scope-specific address space specific to a source region that includes the source node. The first hop including the first hop node and the second hop node, both in the network path, may be identified with respect to the destination node by a destination hop identifier in the destination scope-specific address space.
The description above with respect to
As described above, sending data via a scope-specific address may include sending the data via a sequence of hops in a network path included in communicatively coupling a source node and a destination node. The source-destination protocol address may include a plurality of hop identifiers respectively identifying the hops in the sequence. They data may be sent via a first path node in a network path communicatively coupling the source node and the destination node. In an aspect, the first path node is not included in the source network region and the first path node is not included a destination network region that includes the destination node. The source-destination protocol address may include a source-first address that, in the source scope-specific address space and for the network protocol, identifies the first path node to the source node. The source-destination protocol address may include a first hop identifier that identifies a first hop in the network path, where the first hop includes at least one of the source node and the first path node
A protocol address that for a network protocol identifies a second node to a first node may include an identifier of a network path included in communicatively coupling a first node and a second node. For example, with respect to
A protocol address that for a network protocol identifies a second node to a first node may include first hop information identifying a first hop including a first pair of communicatively coupled nodes included in communicatively coupling the first node and the second node. The sequence, 100.101.103.102.103.102, described in the previous paragraph includes the hop identifier “101” which identifies a fifth hop 10508c5 in the network 10500c. The first hop 10502c5 includes a fourth path node 10504c4 and a second path node 10504c2, included in a network path that communicatively couples the first node 10502c1 and the eleventh node 1050210c11.
A hop identifier in a protocol address may include at least one of the first node and the second node. The hop identifier may include a network interface identifier of a network interface of a node in the hop. In network 10500b in
A protocol address that for a network protocol identifies a second node to a first node may be defined by a network protocol to include a network interface identifier identifying a network interface included in communicatively coupling a first node and a second node. With respect to
As described above, a protocol address may be identified that, in a second scope-specific address space specific to a second network region that includes the second node, identifies the first node. The protocol address that identifies the second node may include address information that identifies the first node. In
As has been described above, a protocol address that for a network protocol identifies a second node to a first node may include a plurality of hop identifiers in an identifiable first order and in an identifiable second order, wherein the protocol address includes the plurality of hop identifiers in the first order and a second-first protocol address, that identifies the first node to the second node, includes the plurality of hop identifiers in the second order. At least one of the first order and the second order may be identified by sequence information defined by a schema of the network protocol in the data unit. The sequence information may be represented separately from the plurality of hop identifiers.
A network may be represented in a topological space. The domain name system includes a hierarchical representation of the Internet, but currently neither the hierarchical structure of the name space nor the hierarchical structure of the IP address space represents communicatively couplings and/or routes in the network.
As described with respect to
Sending data in a data unit by a first node may include detecting, in the data unit, address separating information specified according to the network protocol for detecting at least one of a first-next protocol address information and a next-first protocol address information. The address separating information may be updated for identifying, by a next node included in communicatively coupling the first node and the second node, the at least one of the first-next protocol address information and next-first protocol address information in the address information, wherein the next-first protocol address information includes information for identifying the first node.
A protocol address, that for a network protocol identifies a second node to a first node, may include a first-PN protocol address that, in the first scope-specific address space specific to the first region, identifies a first path node (PN) included in a first network path included in communicatively coupling the first node and the second node.
Additionally or alternatively, a protocol address, that for a network protocol identifies a second node to a first node, may include a PN-second protocol address that, in the PN scope-specific address space specific to a PN region that includes the path node, identifies the second node. The path node is included in a network path that communicatively couples the first node and the second node Further, identifying a protocol address that for a network protocol identifies a second node to a first node may include identifying, based on the protocol address, the first-PN protocol address and based PN-second protocol address
Sending data from a first node to a second node identified by a may include sending the data via a path node in a network path communicatively coupling the first node and the second node. The path node, in an aspect, is not included in a first network region that includes the first node and the path node is not included a second network region that includes the second node. The protocol address may include a first-PN address that, in the first scope-specific address space and for the network protocol, identifies the path node to the first node and the protocol address includes a PN-second address that, in a PN-scope-specific address space specific to a PN network region that includes the path node, identifies the second node to the first path node for the network protocol
Further, a protocol address that for a network protocol identifies a second node to a first node may include a first hop identifier that identifies a first hop in a network path. The first hop may one or both of the first node and the first path node. A first hop identifier may be assigned from the first scope-specific address space to identify the first hop in response to a negotiation between the first node and another node in the first hop. A protocol address that for a network protocol identifies a second node to a first node may include a second hop identifier that identifies a second hop in the network path, wherein the second hop includes at least one of the second node and the first path node
A protocol address that for a network protocol identifies a second node to a first node may include a hop identifier that identifies a hop in the network path. The hop identifier may, in a scope-specific address space specific to a network region that includes one of a pair of nodes in the first hop, identify the other one of the pair of nodes. The hop includes a first hop node and a second hop node that are communicatively coupled via a first network interface in the first hop node and via a second network interface in the second hop node. The first hop identifier may include at one or more of a first network interface identifier identifying the first network interface and a second network interface identifying the second network interface to at least one of the first hop node and the second hop node
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
To the accomplishment of the foregoing and related ends, the descriptions and annexed drawings set forth certain illustrative aspects and implementations of the disclosure. These are indicative of but a few of the various ways in which one or more aspects of the disclosure may be employed. The other aspects, advantages, and novel features of the disclosure will become apparent from the detailed description included herein when considered in conjunction with the annexed drawings.
It should be understood that the various components illustrated in the various block diagrams represent logical components that operate to perform the functionality described herein and may be implemented in software, hardware, or a combination of the two. While at least one of these components are implemented at least partially as an electronic hardware component, and therefore constitutes a machine, the other components may be implemented in software that when included in an execution environment constitutes a machine, hardware, or a combination of software and hardware.
More particularly, at least one component defined by the claims is implemented at least partially as an electronic hardware component, such as an instruction execution machine (e.g., a processor-based or processor-containing machine) and/or as specialized circuits or circuitry (e.g., discreet logic gates interconnected to perform a specialized function). Other components may be implemented in software, hardware, or a combination of software and hardware. Moreover, some or all of these other components may be combined, some may be omitted altogether, and additional components may be added while still achieving the functionality described herein. Thus, the subject matter described herein may be embodied in many different variations, and all such variations are contemplated to be within the scope of what is claimed.
In the description above, the subject matter is described with reference to acts and symbolic representations of operations that are performed by one or more devices, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processor of data in a structured form. This manipulation transforms the data or maintains it at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the device in a manner well understood by those skilled in the art. The data is maintained at physical locations of the memory as data structures that have particular properties defined by the format of the data. However, while the subject matter is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that various of the acts and operation described hereinafter may also be implemented in hardware.
To facilitate an understanding of the subject matter described above, many aspects are described in terms of sequences of actions that may be performed by elements of a computer system. For example, it will be recognized that the various actions may be performed by specialized circuits or circuitry (e.g., discrete logic gates interconnected to perform a specialized function), by program instructions being executed by one or more processors, or by a combination of both. The description herein of any sequence of actions is not intended to imply that the specific order described for performing that sequence must be followed.
Moreover, the methods described herein may be embodied in executable instructions stored in a computer readable medium for use by or in connection with an instruction execution machine, system, apparatus, or device, such as a computer-based or processor-containing machine, system, apparatus, or device. As used here, a “computer readable medium” may include one or more of any suitable media for storing the executable instructions of a software component in one or more forms including an electronic, magnetic, optical, and electromagnetic form, such that the instruction execution machine, system, apparatus, or device may read (or fetch) the instructions from the non-transitory computer readable medium and execute the instructions for carrying out the described methods. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, software components or other data. Computer storage media includes, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM); Electrically Erasable Programmable Read Only Memory (EEPROM); flash memory or other memory technology; portable computer diskette; Compact Disk Read Only Memory (CDROM), compact disc-rewritable (CDRW), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by an execution environment.
Communication media typically embodies computer readable instructions, data structures, software components, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
Thus, the subject matter described herein may be embodied in many different forms, and all such forms are contemplated to be within the scope of what is claimed. It will be understood that various details may be changed without departing from the scope of the claimed subject matter.
The use of the terms “a” and “a” and “the” and similar referents in the context of describing the subject matter (particularly in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the scope of protection sought is defined by the claims as set forth hereinafter together with any equivalents thereof entitled to. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illustrate the subject matter and does not pose a limitation on the scope of the subject matter unless otherwise claimed. The use of the term “based on” and other like phrases indicating a condition for bringing about a result, both in the claims and in the written description, is not intended to foreclose any other conditions that bring about that result. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention as claimed.
The use of “including”, “comprising”, “having”, and variations thereof are meant to encompass the items listed thereafter and equivalents thereof as well as additional items and equivalents thereof. Terms used to describe interoperation and/or coupling between components are intended to include both direct and indirect interoperation and/or coupling, unless otherwise indicated. Exemplary terms used in describing interoperation and/or coupling include “mounted,” “connected,” “attached,” “coupled,” “communicatively coupled,” “operatively coupled,” “invoked”, “called”, “provided to”, “received from”, “identified to”, “interoperated” and similar terms and their variants.
As used herein, any reference to an entity “in” an association is equivalent to describing the entity as “included in and/or identified by” the association, unless explicitly indicated otherwise.
Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. Although methods, components, and devices similar or equivalent to those described herein can be used in the practice or testing of the subject matter described herein, suitable methods, components, and devices are described below.
All publications, patent applications, patents, and other references mentioned herein are incorporated by reference in their entirety. In case of conflict, the present disclosure, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and not intended to be limiting.
One or more aspects of the disclosure are described with reference to the drawings, wherein like reference numerals are generally utilized to refer to like elements throughout, and wherein the various structures are not necessarily drawn to scale. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more aspects of the disclosure. It may be evident, however, to one skilled in the art, that one or more aspects of the disclosure may be practiced with a lesser degree of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing one or more aspects of the disclosure. It is to be understood that other embodiments and/or aspects may be utilized and structural and functional modifications may be made without departing from the scope of the subject matter disclosed herein.
An exemplary device included in an execution environment that may be programmed, adapted, modified, and/or otherwise configured according to the subject matter is illustrated in
Processor 20104 may access instructions and data via one or more memory address spaces in addition to the physical memory address space. A memory address space includes addresses identifying locations in a processor memory. The addresses in a memory address space are included in defining a processor memory. Processor 20104 may have more than one processor memory. Thus, processor 20104 may have more than one memory address space. Processor 20104 may access a location in a processor memory by processing an address identifying the location. The processed address may be identified by an operand of an instruction and/or may be identified by a register and/or other portion of processor 20104.
Physical processor memory 20106 may include various types of memory technologies. Exemplary memory technologies include static random access memory (SRAM), Burst SRAM or SynchBurst SRAM (BSRAM), Dynamic random access memory (DRAM), Fast Page Mode DRAM (FPM DRAM), Enhanced DRAM (EDRAM), Extended Data Output RAM (EDO RAM), Extended Data Output DRAM (EDO DRAM), Burst Extended Data Output DRAM (BEDO DRAM), Enhanced DRAM (EDRAM), synchronous DRAM (SDRAM), JEDEC SRAM, PC 20100 SDRAM, Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), SyncLink DRAM (SLDRAM), Ferroelectric RAM (FRAM), RAMBUS DRAM (RDRAM) Direct DRAM (DRDRAM), and/or XDRTM DRAM. Physical processor memory 20106 may include volatile memory as illustrated in the previous sentence and/or may include non-volatile memory such as non-volatile flash RAM (NVRAM) and/or ROM.
Persistent secondary storage 20108 may include one or more flash memory storage devices, one or more hard disk drives, one or more magnetic disk drives, and/or one or more optical disk drives. Persistent secondary storage may include a removable data storage medium. The drives and their associated computer readable media provide volatile and/or nonvolatile storage for computer-executable instructions, data structures, software components, and other data.
Execution environment 20102 may include software components stored in persistent secondary storage 20108, in remote storage accessible via a network, and/or in a processor memory.
Execution environment 20102 may receive user-provided information via one or more input devices illustrated by an input device 20128. Input device 20128 provides input information to other components in execution environment 20102 via input device adapter 20110. Execution environment 20102 may include an input device adapter for a keyboard, a touch screen, a microphone, a joystick, a television receiver, a video camera, a still camera, a document scanner, a fax, a phone, a modem, a network interface adapter, and/or a pointing device, to name a few exemplary input devices.
Input device 20128 included in execution environment 20102 may be included in device 20100 as
An output device 20130 in
A device included in and/or otherwise providing an execution environment may operate in a networked environment communicating with one or more devices via one or more network interface components.
Some components, illustrated in the drawings are identified by numbers with an alphanumeric suffix. A component may be referred to generically in the singular or the plural by dropping a suffix of a portion thereof of the component's identifier. For example, execution environments; such as execution environment 20401a, execution environment 20401b, and their adaptations and analogs; are referred to herein generically as an execution environment 20401 or execution environments 20401 when describing more than one. Other components identified with an alphanumeric suffix may be referred to generically or as a group in a similar manner.
Some or all of the exemplary components illustrated in
An application, such as a networking application 20403a and/or a t-service 20405b, operating in a node 20502, may exchange data via a network with another node 20502 by interoperating with one or more components of a corresponding network stack 20407. In
Transport layer protocols supported by connectionless component 20411a and by connection-oriented component 20413a generate transport layer data units to include data received from an operatively coupled application and/or a higher layer protocol component to deliver the data via the data units according to a network layer protocol to a transport layer protocol endpoint, accessed via a socket, in another node 20502. Analogously, data sent via an application in another node via a transport layer component may be received according to the network layer protocol by a compatible transport layer component, such as a connection-oriented component 20413a and/or by a connectionless component 20411a, to deliver to another protocol layer and/or to an application operating in the execution environment 20401a in the receiving other node 20502.
A network layer protocol is designed and configured to deliver data across one or more communication links and/or networks between nodes in a network or internet. In
One or more link layer protocols may be included in communicatively coupling a source node 20502 and a destination node 20502 via a network path that includes one or more path nodes 20504 as illustrated in
For ease of illustration, the description that follows focuses on IP networks and protocols in the TCP/IP suite due to their wide use and because they are well-known in the art. Those skilled in the art will understand that the scope of the subject matter described is not limited to IP networks nor is it limited to network layer protocols. For example, the subject matter of this disclosure is applicable to the exchanging data via one or more link layer protocols via one or more physical links.
With respect to
A network layer component 20415a operating in a node 20502 may communicate with one or more nodes 20502 over a LAN, a link, and/or a network of networks such as an intranet or the Internet. A network layer component 20415a in the node 20502 may receive transport layer data units, for example, formatted as TCP packets from a connection-oriented layer component 20413a and/or transport layer data units formatted as UDP packets from a connectionless component 20411a illustrated in
Analogously, the network layer component 20415a may interpret data, received from a link layer component 20425a in the node 20502b, as IP protocol data and may detect IP packets in the received data. The network layer component 20415a may strip off IP layer specific data and transfer the payload of one or more IP packets to the connection-oriented layer component 20413a and/or to the connectionless component 20411a to process as transport layer data units according to a particular transport layer protocol.
As described above,
In addition to the protocols described above, protocols corresponding to layers in the OSI model above the transport layer may be included in communicating via a network. The term “application protocol” as used herein refers to any protocol or combination of protocols that correspond to one or more layers in the OSI reference model above the transport layer. Programs and executables operating in execution environments 20401 may communicate via one or more application protocols. Exemplary application protocols include a hypertext transfer protocol (HTTP), various remote procedure call (RPC) protocols, various instant messaging protocol, email protocols, and various presence protocols.
Data exchanged between nodes 20502 in a network 20500 may be exchanged via data units of one or more protocols. Each layer of a network stack may provide a layer specific protocol component. Some protocols, combine services from multiple layers of the OSI model into a single layer such as the SYSTEMS NETWORK ARCHITECTURE (SNA) protocol. Still others may take a hybrid approach. With the advent of software defined networking and flexible protocols such as OPENFLOW, new protocols and variations of existing protocols are being introduced and will be introduced that are within the scope of the subject matter of the present disclosure.
A network protocol is defined by one or more formatting rules and/or a vocabulary referred to as a schema. The schema defines valid data units to exchange between and/or among protocol endpoints defined by the respective network protocol. A network protocol also specifies and/or otherwise is compatible with one or more address spaces for identifying protocol endpoints for exchanging data. The terms “identifier space” and “address space” are used interchangeably herein. For example, various versions of hypertext transfer protocol (HTTP) specify a format for HTTP uniform resource locators (URL). HTTP specifies a location in an HTTP header that identifies a URL as an identifier or address from the HTTP address space that identifies both a resource and recipient of an HTTP data unit. The transmission control protocol (TCP) specifies a format and vocabulary for a TCP header including a destination protocol endpoint field for including what the TCP refers to as a destination port number that, when combined with a destination protocol address from an IP packet, identifies a transport layer protocol endpoint of a receiver of data included in a TCP data unit. A sending endpoint is similarly identified by a source port number included in a source protocol endpoint field of a TCP data unit and a source protocol address from an IP data unit.
Other exemplary address spaces that identify protocol endpoints in various protocols include an email address space identifying a protocol endpoint for the simple mail transfer protocol (SMTP), a telephone number address space for various telephony protocols, instant message address spaces for various instant message protocols, and media access control (MAC) addresses for various link layer protocols, to name just a few examples.
Since addresses from address spaces at various layers of a network stack are often not suited for remembering and/or identifying by users, an address space of symbolic identifiers or names may be used to provide aliases for addresses in an address space identifying protocol endpoints corresponding to a protocol supported by a layer of a network stack. The domain name space is a well-known identifier space of names for identifying nodes and/or network interfaces as protocol endpoints of the IP protocol in the Internet, private internets, and intranets. The domain name system (DNS) is a collection of domain name system services maintaining databases that associate names from the domain name space with protocol addresses, in particular with IP addresses. The domain name space defines a global name space shared across the Internet.
In
Operational Details and Aspects
With reference to
With reference to
For example, the arrangement in
In
For example, the arrangement in
Address information and path information may be detected in various ways as described herein. With respect to
The first node 20502a1 may identify a protocol endpoint in a node outside the first region 20510a1 by a protocol address from, for example a first scope-specific address space specific to the first region 20510a1. The protocol address identifies the node including the protocol endpoint and identifies a network interface of the node. With respect of
The address information and/or path information may be received in a data unit of a network protocol supported by a network layer component 20415a. Networking application 20403a in the first node 20502a1 may provide data to send to the second node 20502a2 by providing address information identifying a protocol address that in the first region identifies the second node 20502a2. The address information may be detected by the address handler component 20416a. The address handler component 20416a may include instructions to generate and/or to store a representation of the protocol address as address information in a data unit specified according to the network protocol, such as the Internet Protocol or an Ethernet protocol, supported by the network layer component 20415a or the link layer component 20425a. The address handler component 20416a may interoperate with a packet generator component 20421a to include the address information in the data unit as specified by the corresponding network protocol. The address information may include and/or or may otherwise identify path information that identifies a network path that communicatively couples the first node 20502a1 and the second node 20502a2.
In
The packet generator component 20421a in the first node 20502a1 may include one or more instructions that when executed by the first node 20502a1 identify a source protocol address based on address information represented in the data unit to identify the first node 20502a1 as the source node of the data in the data unit. The packet generator component 20421a may interoperate with a t-space component 20404a to receive the source address information to include a representation of the source protocol address in the data unit.
A t-space component 20404a in the first node 20502a1 may identify a source protocol address that, in a second scope-specific address space specific to the second region 20510a2 that includes the second node 20502a2, identifies the first node 20502a1. The second scope-specific address space may be node-specific. The identifier, 201.201.200.203, identifies a sequence of network interfaces and hops in a network path from the second node 20502a2 to the first node 20502a1. In a second node-specific address space specific to the second node 20502a2, the identifier identifies the first node 20502a1. The source protocol address may be pre-specified to the first node 20502a1 via a user and/or may be determined based on a previous communication with the second node 20502a2. The source protocol address may be retrieved via a request to a network directory service, as described in more detail below and referred to herein as a “topology service”.
A packet generator component 20421a may receive source address information that identifies a scoped address that identifies the first node 20502a1 in the first region 20510a1. In one aspect, illustrated in
The second node 20502a2, in
The second node may receive a first message via one or more data units that identify 202.202.203.203 as a protocol address of the second node 20502a2. The first message may be sent by a t-communication component 20410a operating in an execution environment 20401a of the first node 20502a1. The first message may include a symbolic identifier, such as a domain name, of the first node 20502a1 to register in a topology service system including a t-service 20405b illustrated in
In an aspect, a topology monitor (t-monitor) component 20408a in an execution environment of the second node 20502a2 may detect the path information, 202.202.203.203 in address information detected in an address field of a data unit and/or from an application operating in the second node 20502a2. The t-monitor component 20408a may provide path information to a t-space component 20404a. The t-space component 20404a may associate the symbolic identifier received via the resolver component 20402a with a location in a topological space identified based on the path information. The location may be associated with symbolic identifier to identify address information which may include an identifier of the first node 20502a1 with respect to the second region 20510a1. The t-space component 20404a may save the association in a local topology data store 20433a, which in an aspect may serve as a cache. Additionally, the second node 20502a2 may forward the symbolic identifier in a second message to be registered in a topology service system, such as the domain name system or an analog of the domain name system. The t-space component 20404a may interoperate with a t-access component 20412a to identify address information stored in a topology data store 20433a to send along with the symbolic identifier. The t-space component 20404a may interact with a topology relay (t-relay) component 20406a to generate the second message to send to deliver to a node including a t-service to register the symbolic identifier.
The second node 20502a2 may send a message to the third node 20502a3 in one or more data units identifying the identifier, 201.202, in a destination address field of the respective data unit(s). The message may include and/or otherwise identify the symbolic identifier received from the first node 20502a1.
In another aspect, the second node 20502a2 may be included in and/or may otherwise provide an instance of the execution environment 20401b. In
The t-communication component 20410b may provide information received in the message, directly and/or indirectly, to a t-space component 20404b to create and/or update the record. Path information may alternatively be received in a request to resolve a symbolic identifier to address information identifying a protocol address. A request to resolve a symbolic identifier may be received by the t-communication component 20410b and/or by a t-peer component 20431b.
The t-space component 20404b may interoperate with a t-monitor component 20408b in execution environment 20401b of the second node 20502a2. The t-monitor component 20408b may receive the address information identifying the sequence, 202.202.203.203, along with a symbolic identifier of the first node 20502a1. The t-monitor component 20408b may provide the address information to a t-space component 20404b to associate with the symbolic identifier as described above. The address information may be associated by determining a location for the first node 20502a1 in a topological space representing some or all of a network. A topological space, stored in a topology data store 20433b, and representing part or all of the network may be updated, via a topology access (t-access) component 20412b, to represent the first node 20502a1 at the location. For example, a record associating the symbolic identifier and the location in the topological space may be created and/or otherwise updated. Such a record may be stored in a topology data store 20433b illustrated in
The t-space component 20404b may additionally forward the symbolic identifier in a second message to be registered in another node, such as the third node 20502a3, in a distributed topology service system. The t-space component 20404b may interoperate with a resolver component 20402b to identify address information and/or location information locating the first node 20502a1 to send along with the symbolic identifier. Location information may identify a location relative to another entity and/or location in a topological space and/or may identify an absolute location based on a coordinate system. The resolver component may interact with a t-relay component 20406b to generate the second message to deliver to a node, such as the third node 20502a3 of an execution environment 20401b including a t-service 20405b, which may register the symbolic identifier and/or forward to yet another t-service in the topology service system.
The second node 20502a2 may send a message to the third node 20502a3 in one or more data units identifying the sequence, 201.202, in a destination address field of the data unit(s). The message may include and/or otherwise identify the symbolic identifier of the first node 20502a1.
As described, the third node 20502a3 may be included in and/or may otherwise provide an instance of the execution environment 20401b, in
The t-communication component 20410b may provide the data unit or a suitable portion thereof, directly and/or indirectly, to the t-monitor component 20408b in interoperating, directly or indirectly, with a t-space component 20404b to create and/or update a representation of a node in a topological space. Address information may alternatively be received in a request to resolve a symbolic identifier to address information identifying a protocol address. A request to resolve a symbolic identifier may be received by the t-communication component 20410b and/or by a t-peer component 20431b.
The third node may associate the symbolic identifier with a third sequence of network interface identifiers, 202.202.203.203.201.202, that identifies the third node 20502a3 in an address space specific to the first node 20502a1. Thus, the first node may be registered with a t-service operating in an execution environment of the third node 20502a3 by the second node 20502a2. The first node 20502a1 need not have access to an address of the t-service 20405b in the third node to register the symbolic identifier of the first node 20502a1. A first node may register with a t-service, unknown to the first node, by sending its symbolic identifier to another node that does have access to a protocol address of node included in and/or providing an execution environment hosting the t-service. If a node receives a symbolic identifier of another node to register and the receiving node does not know the address of a topology node hosting a t-service, the receiving node may forward the symbolic identifier to still another node that might have access to a protocol address of the topology node. The symbolic identifier may be forwarded among nodes until a node including a t-service (i.e. a topology node) is located. As the symbolic identifier is forwarded path information, hop information, network interface information, and scope specific address information may be collected to deliver to a t-service.
As described herein, a first node may detect address information and/or path information that identifies a first-second protocol address that, in a first scope-specific address space specific to a first region that includes the first node, identifies the second node. Alternatively or additionally, the second node may detect address information that identifies a second-first protocol address that, in a second scope-specific address space specific to a second region that includes the second node, identifies the first node to the second node. Alternatively or additionally, the second node may receive address information identifying the first-second protocol address. The second node may determine the second-first protocol address based on the first-second protocol address. Alternatively or additionally, the first node may receive the second-first protocol address. The first node may determine the first-second protocol address based on the second-first protocol address.
Returning to
A t-space component 20404b in the third node 20503a3 may determine an address space that includes a protocol address identified by the address information. For example, the t-space component 20404b may identify that a protocol address detected in the address information is in a third scope-specific address space specific to a third region 20510a3 that includes the third node 20502a3 in detecting an identifier of a node, such as the second node 20502a2, that sent the data in the received data unit.
When the protocol address, identified in address information is detected by the t-space component 20404b, is not in an address space that is usable for sending data to another node, the t-space component 20404b may determine a protocol address in a suitable address space as described in more detail below. In one aspect, the t-space component 20404b may receive address information that identifies the third node, in a second scope-specific address space of the second node that sent the data unit. The t-space component 20404b may determine a third-second protocol address, that in a third node-specific address space specific to the third node, identifies the second node 20502a2. In another aspect, the address information may identify a global or local scoped address.
With respect to
At the first node 20502a1, an address handler component 20416a and/or a t-space component 20404a operating in the first node 20502a1 may set and/or otherwise detect a value in the address separator field 20604a that indicates a first address field 20608a has a zero size. The entire address information field 20606a, thus, constitutes a second address field 20610a at the first node 20502a1 and identifies the first-second protocol address that may be set and/or otherwise detected by the address handler component 20416a.
At a third path node 20504a3, an address separator field 20604a in a data unit including the data from the first node 20502a1 may be set to and/or otherwise may be detected, by an address handler component 20416a and/or a t-space component 20404a in the third path node 20504a3, as a value that identifies 202.202 in a first address field 20608a. The information in the first address field 20608a identifies a protocol address that, in the first scope-specific address space identifies the third path node 20504a3. The value in the address separator field also identifies a second address field 20610a that identifies 203.203 as a protocol address that, in a fifth scope-specific address space specific to a fifth region 20510a5 including the third path node 20504a3, identifies the second node 20502a2.
At the second node 20502a2 a data unit including the data from the first node 20502a1 may include a value, set and/or detected by an address handler component in the second node 20502a2, in an address separator field 20604a that indicates that the address information field 20606a includes only a first address field 20608a identifying 202.202.203.203 as the first protocol address.
As the data from the first node 20502a1 is transmitted from node to node in the network path the value represented in an address separator field 20604a in an address information field 20606a in a data unit including the data or a portion thereof may be adjusted by respective address handler components 20416a in the nodes in the network path to identify a protocol address in a suitable address space for the respective nodes.
In an aspect, at the second node 20502a2, the value in the separator address field may indicate to a t-space component 20404a that address information field 20606a also includes information for determining and/or otherwise identifying a second-first protocol address, that in the second scope-specific address space, identifies the first node 20502a1. An example and description are provided below.
The above describes an address representation 20602a in the role of identifying destination address information in a data unit of a network protocol, such as an IP protocol or an Ethernet frame. An address representation 20602a may include source address information with respect to a node receiving a data unit sent from the first node 20502a1 to the second node 20502a2. An address information field 20606a including source address information at the third path node 20504a3 may include a first address field 20608a identifying the sequence, 200.203, that identifies a protocol address that, in the fifth scope-specific address space specific to the first region 20510a5, identifies the first node 20502a1 as the source node for the data in the data unit. The address information field 20606a including the source address information at the third path node 20504a3 may include a second address field 20610a identifying the sequence, 201.201, that identifies a protocol address that, in the second node-specific address space specific to the second region 20510a2, identifies the third path node 20504a3 as a path node in the network path traversed by the data sent from the first node 20502a1.
A data unit may include separate address representations for destination address information and source address information as, for example, current IP packet headers are specified. Alternatively, a data unit such as an IP packet may include an address representation that identifies source address information in the context of one address space specific to a node, in a region, in a network path traversed by the data unit and identifies destination address information to another node, in another region in the network path. Rather than requiring separate source and destination representations, a single address representation may identify some or all of a destination protocol address with respect to one scope-specific address space and some or all of a source protocol address with respect to another scope-specific address space. More details, as well as examples, are described below.
In
A first node 20502c1 may identify a second node 20502c2 by a first-second protocol address, that in a first scope-specific address space specific to a first region 20510c1 including the first node 20502c1, identifies the second node 20502c2. The first-second protocol address may include and/or otherwise may be based on a sequence of hop identifiers 200.200.201.203.202.201. Note that other network paths are illustrated for transmitting data from the first node 20502c1 to the second node 20502c2 and may also be and/or otherwise may identify protocol addresses in the first scope-specific address space that identify the second node 20502c2 to nodes in the first region 20510c1. Note that the second path node 20504c2 includes a network interface that is in the first region 20510c1 and a network interface that is not in the first region. In communicating with the second node 20502c2 via the network interface outside the first region 20510c1 the second path node 20504c2 is defined to be outside the first region 20510c1. When the second path node 20504c2 communicates with a node outside the first region 20510c1 via the second path node's 20504c2 network interface in the first region 20510c1, the second path node 20504c2 is defined to be in the first region 20510c1. For example when the second path node 20504c2 communicates with a twelfth node 20502c12 via fourth node 20502c4, the second path 20504c2 is in the first region 20510c2 with respect to the twelfth node 20502c12.
The second node 20502c2 may identify a third node 20502c3 by a second-third protocol address that, in a second node-specific address space specific to the second node 20502c2 in the second region 20510c2, identifies the third node 20502c3. The protocol address may be based on a sequence of hop identifiers, 201.203.200, that identifies the third node 20502c3 with respect to the second node 20502c2. The third node 20502c3 is in a third region 20510c3. Within the third region 20510c3, the third node 20502c3 may be identified by a local-scope address 200. Nodes in the third region 20510c3 may identify nodes outside the third region 20510c3 with identifiers from a third scope-specific address space specific to the third region 20510c3.
The hop identifiers, 200.201.203.202.201, may be represented in an address representation 20602c in a data unit for sending data from the first node 20502c1 to the second node 20502c2. The hop identifiers, 201.203.200, may be represented in an address representation 20602c in a data unit for sending data from the second node 20502c2 to the third node 20502c3. The identifiers may be given a bit or binary representation and the hop identifiers may be distinguished or separated via address separator fields 20604c as described above with respect to
Note that the address information that identifies protocol addresses for the second node 20502c2 and for the third node 20502c3 in the preceding description may include information for identifying a return path or a portion thereof. For example, the second-third protocol address, 201.203.200, identifies 203.201, which may be a portion of a third-second protocol address that, in the third scope-specific address space, identifies the second node 20502c2 for nodes in the third region 20510c3. The first-second protocol address, 200.201.203.202.201, identifies 201.202.203.201 that, in the second-node-specific address space, identifies a network path from the second node to the first region 20510c1. Note that the second node may be in a region that includes only one node. The sequence, 201.202.203.201, however, does not identify any network interfaces of nodes in the first region 20510c1. Separate source address information may be included in a data unit sent to the second node 20502a2 that includes data sent from the first node 20502c1. The source address information may identify 201.202.203.201.101 as a second-first protocol address that, in the second node-specific address space, identifies the first node 20502c2. In, the first region 20510c1, 101 may be a scoped address that identifies the first node 20502c1 in the scope of the first region 20510c1. Thus, a scope-specific address may include a scoped address.
As described in the previous paragraph, a hop may be assigned an identifier that is shared by the pair of nodes in the hop. Thus, a sequence of hop identifiers may serve as a scope-specific address in one scope-specific address space when processed in one order of the sequence and may serve as another scope-specific address specific to another node when processed according to another order of the sequence. Any of the address types illustrated in
An address separator field 20604d includes series of 1-valued bits and 0-valued bits. A change from a 1-value to a 0-value and vice versa may indicate a boundary that separates protocol endpoint identifiers and/or interface identifiers. An address separator field 20604d1 includes one 0-valued bit followed by four 1-valued bits. The 0-valued bit may be defined to indicate that a first network interface in a first hop identifier is one bit long with a corresponding position in the address information field 20606d.
Note that the address separator field 20604d6 does not identify a pair of identifiers and is similar to address separator fields 20604c in
In
Note that reversing the interface identifiers yields the identifier, 2010-20151.20294-20151, that may be a protocol address that, in a second node-specific address space specific to the second node 20502b2, identifies the first node 20502b1. The second node 20502b2 and a third node 20502b3 may be included in regions that respectively include the nodes. Each of the two nodes may identify the other by a protocol address in a respective node-specific address space. A sequence of pairs of interface identifiers, 2010-20294.20151-2010, may be a protocol address, that in the second node-specific address space, identifies the third node 20502b3. Reversing the interface identifiers yields the identifier, 2010-20151.20294-2010, that may be a protocol address, that in a third node-specific address space specific to the third node 20502b3, identifies the second node 20502b2.
A sequence of hop identifiers based on interface identifiers may serve as a scope-specific address in one scope-specific address space when processed in one order of the sequence and may serve as another scope-specific address specific to another node when processed according to another order of the sequence.
See application Ser. No. 11/962,285, by the present inventor, filed on 2007 Dec. 21, entitled “Methods and Systems for Sending Information to a Zone Included in an Internet Network” for a description of addresses having outside scope and/or inside scope and processing of such addresses. A third address information field 20606e3 corresponding to a third address separator field 20604e3 may include a pair of identifiers as described with respect to
In
In another aspect, scope-specific addresses for a first node, a second node, and a third node may conform to a currently known schema defining a valid Internet Protocol address as specified by RFC 791 and/or RFC 3513. The protocol addresses may be processed as scope-specific as opposed to interpreting them as from a global address space as is currently done. A pattern in a type field may indicate a protocol address is scope-specific. In a further aspect, a mapping may be specified between scope-specific address spaces. A mapping may be ruled-based and/or may be specified by associations such as represented by a lookup table.
In an aspect, a node, referred to as a first origin node, in a network in a first region having a first scope-specific address space may assign a protocol address, of a network protocol, identifying a location of a representation of the node as an origin according to a coordinate system for a metric space that includes a network topology representing the network based on the network protocol. Alternatively or additionally, a network interface of an origin node may be identified by a coordinate identifying the origin of the coordinate space in the metric space. Another node, referred to as a second origin node, in the network in a second region having second scope-specific address space may assign a protocol address identifying a location of a representation of the other node as an origin according to a second coordinate system for the metric space that includes the network topology representing the network. The first scope-specific address space includes identifiers from the first coordinate system based on the first origin node location and the second scope-specific address space includes identifiers from the second coordinate system based on the second origin node location
Those skilled in the art of metric spaces, such as geometric spaces, will appreciate that a one-to-one mapping may be determined and/or otherwise identified for mapping addresses from a first coordinate space having a first origin for a metric space to addresses from a second coordinate space having a second origin in the metric space. Given a mapping rule between the first scope-specific address space and the second scope-specific address space and a mapping between the second scope-specific address space and third scope-specific address space based on a third coordinate space identifying a third origin in the metric space, a mapping from the first coordinate space to the third coordinate space may be determined. A mapping between coordinate spaces for a metric space may include a coordinate shift and/or a rotation, for example. The mapping may be pre-specified and accessible to nodes in one or both address spaces. Mapping between locations in a number of different metric spaces are well known in mathematics.
Nodes may exchange mapping information. In an aspect, the address information may identify a mapping rule when exchanged between nodes. The mapping rule may be determined by second node and sent to a first node. The mapping rule may include mapping information for mapping addresses from the third scope-specific address space to the first scope-specific address space. Those skilled in the art will see that given address information for protocol addresses from any two scope-specific address spaces identifying respective origin locations in a metric space including a representation of a network and given a protocol address of third node not included in a region of either of the two scope-specific address spaces, a mapping rule may be determined by a resolver component to map the protocol address of the third node in one of the two scope-specific address spaces to the other to identify the third node in the other scope-specific address space.
Exemplary metric spaces include Euclidean spaces, non-Euclidean spaces, and geometric spaces. A Cartesian coordinate system is an exemplary address space for a Euclidean space. Another example of a geometric address space is a geospatial address space such as used currently in geo-location services. Networks have topologies that may be represented in a geo-space including locations addressed via a geometric address space. A metric space including a network topology of a network may be multi-dimensional space. For example, nodes are included in a real-world three-dimensional space that may be associated with a geospatial address space. In one aspect, locations of nodes in a network topology in a metric space may be located based on any suitable metric. Exemplary metrics may measure and/or otherwise may be based on physical distance in the real world between nodes, data transmission times, energy unitization, network congestion, latency, and the like. Exemplary metric spaces include non-Euclidean spaces as well as Euclidean spaces.
A first node, a second node, and a third node may be represented in a metric space. A first path in the metric space connecting the representation of the first node to the representation of the second node may be identified based on a first path location identifier that identifies a location in the first path of a representation of a node, a network interface in the node, a NIC in the network interface, and/or a hop that includes the node in a first network path communicatively coupling the first node and the second node. A second path in the metric space connecting the representation of the second node to the representation of the third node may be identified based on a second path location identifier that identifies a location in the second path of a representation of a node, a network interface in the node, a NIC in the network interface, and/or a hop that includes the node in a second network path communicatively coupling the second node and the third node. A first-third protocol address, that identifies the third node with respect to the first node for a network protocol, may be determined based on the first path location identifier and/or the second path location identifier. The first-third protocol address may include the first path location identifier and/or the second path location identifier.
The first path location identifier may be a relative identifier that identifies the representation in the first path relative to a first location identifier identifying a first location, in the metric space, that includes a representation of the first node or relative to a second location identifier identifying a second location, in the metric space, that includes a representation of the second node. Analogously, the second path location identifier may also be a relative identifier that identifies the representation in the second path relative to the second location identifier or relative a third location identifier identifying a third location, in the metric space, that includes a representation of the third node. The first-third protocol address may be determined based on at least one of the first path location identifier and the third path location identifier. The first-third protocol address may be relative identifier that identifies the third node relative to the first node. The first-third protocol address may include a third location identifier that identifies the third location relative to the first location identifier.
In
A third message 20705a illustrates interoperation between the resolver component 20402a and a t-space component 20404a to associate the first path information with the symbolic identifier as describe above. The registration request in the second message 20703a may be provided to the t-service in the second node 20702a2 to create and/or update a record associating the symbolic identifier and the first information and/or with topology information for determining the first path/address information.
A fourth message 20707a illustrates a data flow included in identifying the second path information by the t-space component 20404a in the second node 20702a2. The second path information may be identified to relay the first symbolic identifier to the t-service in the third node 20702a3 to register the first node 20702a1. The second path information may be accessed from a t-service as described above and/or may be detected by a t-monitor component 20408a in address information in a data unit exchanged between a node communicatively coupled to the second node 20702a2 via the third node 20702a3 and/or from a node communicatively coupled to the third node 20702a3 via the second node 20702a2.
The t-service 20405b in the third node 20702a3 may represent a domain in a structured domain space, such as the domain name space of the Internet that has a hierarchical structure. When the symbolic identifier is not in a domain of the t-service 20405b in the second node 20702a2, the t-service 20405b may forward the request for routing by a t-relay component 20406b interoperating with a t-peer component 20431b in a topology service system a t-service in another node that represents the domain of the symbolic identifier. Additionally or alternatively, the third node 20502a3 may forward the request for delivery to yet another node in the topology service system.
Exemplary topology service systems include the Internet domain name system, a lightweight directory access protocol (LDAP) system, and a Windows® directory. In addition to storing information for lookup based on a symbolic identifier, a t-service may include and/or may interoperate with one or more services that maintain a topology of some or all of a network based on address information exchanged between and among nodes. Resolving a symbolic identifier may include determining some or all of a route between nodes in a topological space. A symbolic identifier may be resolved to more than one instance of address information, which may identify more than one protocol address for transmitting data from one node to another.
Once the third node 20702a3 resolves a symbolic identifier it may cache and/or otherwise store an association between the symbolic identifier and the determined protocol address for later use. Note that a symbolic identifier may be resolved to one or more protocol addresses from the same scope-specific address space and/or different scope-specific address spaces, path-based address spaces, and the like.
The description above with respect to
Returning to
The t-space component 20404b may locate address information associated with the symbolic identifier stored in a record or via another association in a topology data store 20433b. If the symbolic identifier is located in the topology data store 20433b, the t-space component 20404b receives and/or otherwise detects address information associated with the symbolic identifier. If the resolver component 20402b determines that the symbolic identifier is not in a domain of the t-service 20403a in the second node 20502a2, the resolver component may request that the t-space component 20404b lookup and/otherwise determine the address information based on routing information collected by topology service system services in various nodes to determine the first-third protocol address via a lookup in a cache (not shown) that stores information received from other t-services operating in other nodes that manage other domains in the name space of symbolic identifiers.
If the symbolic identifier is not located in the cache, the resolver component 20402b may instruct the t-peer component 20431b in the second node 20502a2 to send the symbolic identifier to a node that includes a t-service that manages the domain that includes the symbolic identifier. The other node may resolve the symbolic identifier, partially resolve the symbolic identifier, and/or may send address information back to the second node 20502a2 for the resolver component 20402a to resolve the symbolic identifier.
As described various types of protocol addresses may conform to various schemas defining rules for formatting valid protocol addresses and/or defining vocabularies specifying valid content of a protocol address. Given first address information identifying a first protocol address and second address information identifying a second protocol address as described above with respect to the method illustrated in
As described above with respect to
Also as described above with respect to
One or more of the t-monitor components 20408 operating in the first node 20502a1 and/or a t-monitor component 20408 in the third node 20502b3 may detect the sequence, 202.202.203.203, and the sequence, 201.202. The sequence, 202.202.203.203, may be provided to the third node 20502a3 by the second node 20502a2, in an example, described in more detail below. The sequence, 201.202, may be provided to the first node 20502a1 by the second node 20502a2 and/or by the third node 20502a3, in an example described in more detail below. Given the two sequences, either or both of the t-space components 20404 in the first node 20502a1 and in the third node 20502a3 may determine a sequence, 202.202.203.203.201.202, and/or another sequence, 202.202.203.202, either or both of which may be a protocol address that, in the first scope-specific address space, identifies the third node 20502a3 for nodes in the first region 20510a1.
Further, t-monitor components 20408 respectively operating in the first node 20502a1 and/or in the third node 20502a3 may similarly detect the sequence, 201.201.200.203, and the sequence, 200.203.201.201, when included in the first address information and the second address information. Given the two sequences, either or both of the t-space components 20404 in the first node 20502a1 and in the third node 20502a3 may determine a sequence, 200.203.201.201.200.203, and/or another sequence, 200.201.200.203, either or both of which may be a protocol address that, in the third node-specific address space, identifies the first node 20502a1 for the third node 20502a3.
A t-space component 20404 operating in the second node 20502a2 may similarly identify protocol addresses for communicating between the first node 20502a2 and the third node 20502a, based on first address information and second address information, as described in the preceding paragraphs.
As
As described above with respect to
Also as described above with respect to
One or more of the t-monitor components 20408 operating respectively in the first node 20502c1 and/or a t-monitor component 20408 in the third node 20502c3 may detect the sequence, 200.201.203.202.201, and the sequence, 201.203.200. The sequence, 200.201.203.202.201, may be provided to the third node 20502c3 by the second node 20502c2. The sequence, 201.203.200, may be provided to the first node 20502c1 by the second node 20502c2 and/or by the third node 20502c3. Given the two sequences, either or both of the t-space components 20404 in the first node 20502c1 and in the third node 20502c3 may determine a sequence, 200.201.203.202.201.201.203.200, and/or another sequence, 200.203.201.202.203.200, either or both of which may be a protocol address that, in the first scope-specific address space, identifies the third node 20502c3 for nodes in the first region 20510c1. Repeated path and/or hop identifiers may indicate a loop in a path in some address representations 20602a as the examples illustrates. A t-space component 20404 may detect loops and remove them to produce shorter protocol addresses. In other address types, loops may be detected by a t-space component 20404 to detect repeated pairs of hop and/or path identifiers where one identifier from a pair is from a source address and the other identifier in the pair is from a corresponding portion of a destination address.
Further, the t-monitor components 20408 respectively operating in the first node 20502c1 and/or in the third node 20502c3 may similarly detect the sequence, 201.202.203.201.101, and the sequence, 201.203.201, when included in the first address information and the second address information, respectively. Given the two sequences, either or both of the t-space components 20404 in the first node 20502c1 and in the third node 20502c3 may determine a sequence, 201.203.201.201.202.203.201.101, and/or another sequence, 201.203.202.201.101, either or both of which may be a protocol address that, in the third scope-specific address space, identifies the first node 20502c1 for nodes in the third region 20510c3.
A t-monitor component 20408 operating in the second node 20502c2 may similarly identify protocol addresses for communicating between the first node 20502c2 and the third node 20502c3, based on first address information and second address information, as described in the preceding paragraphs.
As described above with respect to
In addition, as described above with respect to
One or more of the t-monitor components 20408 operating respectively in the first node 20502b1 and/or a t-monitor component 20408a in the third node 2050b3 may detect the sequence, 20151-20294.20151-2010, and the sequence, 2010-20294.20151-2010. The sequence 20151-20294.20151-2010 may be provided to the third node 20502b3 by the second node 20502b2. The sequence 2010-20294.20151-2010 may be provided to the first node 20502b1 by the second node 20502b2 and/or by the third node 2050bc3. Given the two sequences, either or both of t-space components 20404 in the first node 20502b1 and in the third node 20502b3 may determine a sequence, 20151-20294.20151-2010. “2010-20294.20151-2010” and/or another sequence, 20151-20294.20151-20294.20151-2010, either or both of which may be a protocol address that, in the first node-specific address space, identifies the third node 20502b3 for the first node 20502c1.
Further, t-space components 20404 respectively operating in the first node 20502b1 and/or in the third node 20502b3 may similarly detect the reverse sequence, 2010-20151.20294-20151, and the reverse sequence, 2010-20151.20294-2010, when included in the first address information and the second address information, respectively. Given the two sequences, either or both of the t-space components 20404 in the first node 20502b1 and in the third node 20502b3 may determine a sequence, 2010-20151.20294-2010. “2010-20151.20294-20151” and/or another sequence, 2010-20151.20294-20151.20294-20151, either or both of which may be a protocol address that, in the third node-specific address space, identifies the first node 20502b1 for the third node 20502b3.
A t-monitor component 20408 operating in the second node 20502b2, as described in more detail below, may similarly identify protocol addresses for communicating between the first node 20502b2 and the third node 20502b3, based on first address information and second address information, as described in the preceding paragraphs.
As described above,
One or more of the t-monitor components 20408 operating respectively in the first node 20502b1 and/or a t-monitor component 20408 in the third node 2050b3 may detect the identical sequences, 20294.2010, respectively included in the first scope-specific address space and the second scope-specific address space. Given the two sequences, either or both of the t-space components 20404 in the first node 20502b1 and in the third node 20502b3 may determine a sequence, 20294.2010.20294.2010, and/or another sequence, 20294.20294.2010, either or both of which may be a protocol address that, in the first scope-specific address space, identifies the third node 20502b3 for nodes in the first network 20506b1.
Further, the t-monitor components 20408 respectively operating in the first node 20502b1 and/or in the third node 20502b3 may similarly detect the sequences, 20151.20151, and 20151.2010. Given the two sequences, either or both of the resolver components 20402 in the first node 20502b1 and in the third node 20502b3 may determine a sequence, 20151.2010.20151.20151, and/or another sequence, 20151.20151.20151, either or both of which may be a protocol address that, in the third scope-specific address space, identifies the first node 20502b1 for nodes in the third network 20506b3. A t-space component 20404 may detect the duplicate identifier 2010 in first corresponding positions in the sequence, along with identifiers 20294 and 20151 in second corresponding positions in the sequence. The t-space component 20404 may also determine that all three identifiers are in the same region 20506b2 where they serve as local scoped addresses. The t-space component 20404 may determine that the identifier 2010 is based on the order in both sequences with respect to other identifiers in the same scope. A t-space component 20404 operating in the second node 20502b2, as described above, may similarly identify protocol addresses for communicating between the first node 20502b2 and the third node 20502b3, based on first address information and second address information, as described in the preceding paragraphs.
A block 20802,
With reference to
With reference to
With respect to
A second message 20703b illustrates a data flow, in the second node, including the topology space component 20404a, operating to determine a first hop identifier for the first hop. See application Ser. No. 13/727,649 filed on 2012 Dec. 27, entitled “Methods, Systems, and Computer Program Products for Assigning an Interface Identifier to a Network Interface”, application Ser. No. 13/727,655 filed on 2012 Dec. 27, entitled “Methods, Systems, and Computer Program Products for Determining a Shared identifier for a Hop in a Network”; and application Ser. No. 13/727,657 filed on 2012 Dec. 27, entitled “Methods, Systems, and Computer Program Products for Determining a Hop Identifier for a Network Protocol”.
A third message 20705b illustrates a message sent by a t-communication component 20410a in the second node 20702b2 to send the first hop identifier to a topology service 20405b in the topology node 20702bt to include a representation of the first node in a first location in a topological space. The first location is identified relative to the second node based on the first hop identifier.
With reference to
With reference to
With reference to
With respect to
A topology monitor component 20408 in the second node 20702c2 may detect, based on address information in a data unit included in the exchange, that the first node 20702c1 is in the first hop that is included in communicatively coupling the second node 20702c2 and the first node 20702c1. The address information may be in a data unit of a link layer protocol and/or a higher layer protocol. A t-monitor component may operate in an appropriate protocol layer of a network stack in the second node 20702c2. A second message 20703c illustrates a data flow, in the topology node 20702ct, including the topology space component 20404b, operating to determine a first location in the topological space relative to the second location, based on the hop information. A third message 20705c illustrates a data flow including a t-access component 20412b and the t-space component 20404b that operate to associate the first node 20702a1 and/or an identifier (such as a symbolic identifier) of the first node 20702a1 with the first location in the topological space stored in a topology data store 20433b.
With reference to
With reference to
With reference to
With respect to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
In another aspect of the method illustrated in
A scope-specific address space may include identifiers that identify locations in a metric space that include a representation of a network topology of the network. The metric space may be a geometric space. In an aspect of the method illustrated in
Analogously, the second-third protocol address may be defined relative to a second origin address that, in the second scope-specific address space, is defined to identify a second location of the second node/region represented in a second metric space. The third-second protocol address may be defined relative to a third origin address that, in the third scope-specific address space, that is defined to identify a third location of the third node/region represented in a third metric space.
Still further, the first-third protocol address may be defined relative to a first origin address that, in the first scope-specific address space, is defined to identify a first location of the first region represented in a first metric space. The third-first protocol address may be defined relative to a third origin address that, in the third scope-specific address space, that is defined to identify a third location of the third node/region represented in a third metric space.
A metric space may be multi-dimensional. One or both of first scope-specific address space and the third scope-specific address space respectively include identifiers that identify locations in a multi-dimensional metric space. The locations may be defined with respect to axes that intersect defining an origin location. The first scope specific address space may include a first origin address that identifies a first origin location. An identifier, for a location in the metric space, in the first scope specific address space may be defined relative to the origin location. Analogous statements may be made for other scope specific address spaces, such as the third scope-specific address space and the second scope specific address space in aspects of the method illustrated in
To the accomplishment of the foregoing and related ends, the descriptions and annexed drawings set forth certain illustrative aspects and implementations of the disclosure. These are indicative of but a few of the various ways in which one or more aspects of the disclosure may be employed. The other aspects, advantages, and novel features of the disclosure will become apparent from the detailed description included herein when considered in conjunction with the annexed drawings.
It should be understood that the various components illustrated in the various block diagrams represent logical components that operate to perform the functionality described herein and may be implemented in software, hardware, or a combination of the two. While at least one of these components are implemented at least partially as an electronic hardware component, and therefore constitutes a machine, the other components may be implemented in software that when included in an execution environment constitutes a machine, hardware, or a combination of software and hardware.
More particularly, at least one component defined by the claims is implemented at least partially as an electronic hardware component, such as an instruction execution machine (e.g., a processor-based or processor-containing machine) and/or as specialized circuits or circuitry (e.g., discreet logic gates interconnected to perform a specialized function). Other components may be implemented in software, hardware, or a combination of software and hardware. Moreover, some or all of these other components may be combined, some may be omitted altogether, and additional components may be added while still achieving the functionality described herein. Thus, the subject matter described herein may be embodied in many different variations, and all such variations are contemplated to be within the scope of what is claimed.
In the description above, the subject matter is described with reference to acts and symbolic representations of operations that are performed by one or more devices, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processor of data in a structured form. This manipulation transforms the data or maintains it at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the device in a manner well understood by those skilled in the art. The data is maintained at physical locations of the memory as data structures that have particular properties defined by the format of the data. However, while the subject matter is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that various of the acts and operation described hereinafter may also be implemented in hardware.
To facilitate an understanding of the subject matter described above, many aspects are described in terms of sequences of actions that may be performed by elements of a computer system. For example, it will be recognized that the various actions may be performed by specialized circuits or circuitry (e.g., discrete logic gates interconnected to perform a specialized function), by program instructions being executed by one or more processors, or by a combination of both. The description herein of any sequence of actions is not intended to imply that the specific order described for performing that sequence must be followed.
Moreover, the methods described herein may be embodied in executable instructions stored in a computer readable medium for use by or in connection with an instruction execution machine, system, apparatus, or device, such as a computer-based or processor-containing machine, system, apparatus, or device. As used here, a “computer readable medium” may include one or more of any suitable media for storing the executable instructions of a software component in one or more forms including an electronic, magnetic, optical, and electromagnetic form, such that the instruction execution machine, system, apparatus, or device may read (or fetch) the instructions from the non-transitory computer readable medium and execute the instructions for carrying out the described methods. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, software components or other data. Computer storage media includes, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM); Electrically Erasable Programmable Read Only Memory (EEPROM); flash memory or other memory technology; portable computer diskette; Compact Disk Read Only Memory (CDROM), compact disc-rewritable (CDRW), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by an execution environment.
Communication media typically embodies computer readable instructions, data structures, software components, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
Thus, the subject matter described herein may be embodied in many different forms, and all such forms are contemplated to be within the scope of what is claimed. It will be understood that various details may be changed without departing from the scope of the claimed subject matter.
The use of the terms “a” and “an” and “the” and similar referents in the context of describing the subject matter (particularly in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the scope of protection sought is defined by the claims as set forth hereinafter together with any equivalents thereof entitled to. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illustrate the subject matter and does not pose a limitation on the scope of the subject matter unless otherwise claimed. The use of the term “based on” and other like phrases indicating a condition for bringing about a result, both in the claims and in the written description, is not intended to foreclose any other conditions that bring about that result. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention as claimed.
The use of “including”, “comprising”, “having”, and variations thereof are meant to encompass the items listed thereafter and equivalents thereof as well as additional items and equivalents thereof. Terms used to describe interoperation and/or coupling between components are intended to include both direct and indirect interoperation and/or coupling, unless otherwise indicated. Exemplary terms used in describing interoperation and/or coupling include “mounted,” “connected,” “attached,” “coupled,” “communicatively coupled,” “operatively coupled,” “invoked”, “called”, “provided to”, “received from”, “identified to”, “interoperated” and similar terms and their variants.
As used herein, any reference to an entity “in” an association is equivalent to describing the entity as “included in and/or identified by” the association, unless explicitly indicated otherwise.
Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. Although methods, components, and devices similar or equivalent to those described herein can be used in the practice or testing of the subject matter described herein, suitable methods, components, and devices are described below.
All publications, patent applications, patents, and other references mentioned herein are incorporated by reference in their entirety. In case of conflict, the present disclosure, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and not intended to be limiting.
An “operating environment” or “computing environment”, as used herein, is an arrangement of hardware and, in some aspects, software that may be further modified, transformed, and/or otherwise configured to include and/or otherwise host an arrangement of components to perform a method of the subject matter described herein. An operating environment includes a processor to execute an instruction included in at least one component of such an arrangement. An operating environment includes and/or is otherwise provided by one or more devices. The operating environment is said to be the operating environment “of” the device and/or devices.
As used herein a “processor” is an instruction execution machine, apparatus, or device. A processor may include one or more electrical, optical, and/or mechanical components that operate in interpreting and executing program instructions. Exemplary processors include one or more microprocessors, digital signal processors (DSPs), graphics processing units, application-specific integrated circuits (ASICs), optical or photonic processors, and/or field programmable gate arrays (FPGAs).
The terms “network node” and “node” in this document both refer to a device having a network interface component (NIC) for operatively coupling the device to a network. Further, the terms “device” and “node” used herein refer to one or more devices and nodes, respectively, providing and/or otherwise included in an operating environment unless clearly indicated otherwise.
As used herein, the term “network protocol” refers to a set of rules and/or conventions that govern how nodes exchange information over a network. The set may define, for example, a convention and/or a data structure. A “data unit”, as the term is used herein, is an entity specified according to a network protocol to transmit data between a pair of nodes in a network path to send the data from a source node to a destination node that includes an identified protocol endpoint of the network protocol. A network protocol explicitly and/or implicitly specifies and/or otherwise identifies a schema that defines one or more of a rule for a format for a valid data unit and a vocabulary for content of a valid data unit. One example of a data unit is an Internet Protocol (IP) packet. The Internet Protocol defines rules for formatting an IP packet that defines a header to identify a destination address that identifies a destination node, and also defines a payload portion to include data to be delivered to the identified destination node. Various address types are specified defining a vocabulary for one or more address fields of an IP data unit. The terms “data unit”, “frame”, “data unit”, and “packet” are used interchangeably herein. One or more data units of a first network protocol may transmit a “message” of a second network protocol. For example, one or more data units of the IP protocol may include a TCP message. In another example, one or more TCP data units may transmit a HTTP message. A message may be empty as may a payload of a data unit.
How data is packaged in one more data units for a network protocol may vary as the data traverses a network path from a source node to a destination node. Data may be transmitted in a single data unit between two consecutive nodes in a network path. Additionally, data may be exchanged between a pair of consecutive nodes in several data units each including a portion of the data. Data received in a single data unit by a node in a network path may be split into portions included in several respective data units to transmit to a next node in the network path. Portions of data received in several data units may be combined into a single data unit to transmit by a node in a network path. For purposes of describing the subject matter, a data unit in which data is received by a node is referred to as a different data unit than a data unit in which the data is forwarded by the node.
A “protocol address”, as the term is used herein, for a network protocol is an identifier of a protocol endpoint of the network protocol when included in an address field of a data unit of the network protocol. For example, 192.168.1.1 is an IP protocol address represented in a human readable format that may be represented in an address field of a header of an IP packet (i.e. an IP data unit) to identify a source and/or a destination IP protocol endpoint. A protocol address differs from a symbolic identifier, defined below, in that a symbolic identifier, with respect to a network protocol, maps to a protocol address. Thus, “www.mynode.com” may be a symbolic identifier for a node in a network when mapped to the protocol address 192.168.1.1. An identifier may be both a symbolic identifier and a protocol address depending on its role with respect to its use for a particular network protocol.
Since a protocol endpoint is accessible by way of a network via a network interface in a node, a protocol address may be processed to identify a node and may be processed to identify a network interface of the node. A network interface may include one or more NICs operatively coupled to a network.
The term “network path” as used herein refers to a sequence of nodes in a network that are communicatively coupled to transmit data in one or more data units of one or more network protocols between a pair of nodes in the network. A node in a pair of nodes in a network path at one end of the sequence of nodes in the network path and/or the other end is referred to herein as a “path end node”. Note that a node may have two NICs with one NIC at each end of a network path. A network path may be included as a portion of another network path that communicatively couples a same pair of nodes. Data may be transmitted via the sequence of nodes in a network path between path end nodes communicatively coupled via the network path. Data may be transmitted in one or both directions depending on an ordering of the nodes in the sequence.
For a network protocol, the term “hop”, as used herein, refers to a pair of consecutive nodes in a network path to transmit, via the network protocol, data sent from a source node to a destination node. A “hop path” is thus a sequence of hops in a network that respectively include a sequence of pairs of consecutive nodes included in transmitting data from a first path end node of the network path to a second path end node of the network path.
The term “path-based protocol address” as used herein refers to a protocol address for a network protocol that includes one or more path segment identifiers that identify one or more respective portions of a network path identified by the path-based protocol address. A “node-based protocol address” is a path-based protocol address that includes a plurality of node identifiers that identify a sequence of nodes in a network path. A “network-interface-based protocol address” is a path-based protocol address that includes a plurality of network interface identifiers that identify a sequence of network interfaces in a network path. A “NIC-based protocol address” is a type of network-interface-based protocol address that includes a plurality of identifiers that identify a sequence of network interface components. A “hop-based protocol address” is a type path-based protocol address since a hop is a type of network path.
Given the above definitions, note that the terms “network path” and “hop” may be defined in terms of network interfaces. A “network path” and a “hop path” include a sequence of network interfaces in a network that are included in transmitting data between a pair of path end nodes in the network. A “hop” refers to at least part of a network path that includes a pair of consecutive network interfaces in a sequence of network interfaces in a network path. A “network path” is thus a sequence of hops in a network that respectively includes a sequence of pairs of consecutive network interfaces included in transmitting data from a first path end node of the network path to a second path end node of the network path.
The term “network topology” or “topology”, for short, as used herein refers to a representation of protocol endpoints, network interfaces, and/or nodes in a network, and representations of communicative couplings between and/or among the protocol endpoints, network interfaces, and/or nodes in the network. A network may have different network topologies with respect to different network protocols and/or with respect to different attributes of a same network protocol. A network topology may represent physical communicative couplings between protocol endpoints, network interfaces, and/or nodes in the network. A network topology may represent logical couplings between protocol endpoints, network interfaces, and/or nodes of a particular network protocol or a particular type of network protocol.
As used herein, an “entity-specific address space” refers to an address space defined for a specific entity where the addresses in the address space operate as identifiers in the context of the entity. An address from an entity-specific address space is referred to herein as an “entity-specific address”. An address is “entity-specific” in that what it identifies is based on the entity to which it is specific. An address may identify one entity in one address space specific to a particular entity and may identify a different entity in another address space specific to a different entity. Addresses in an entity-specific address space operate as identifiers in the context of an entity to which they are “specific” as defined by the specific association of the address space and the entity. Without knowledge of the entity to which an entity-specific address space is specific, what an address in the entity-specific address space identifies is indeterminate. The terms “entity-specific address” and “entity-specific identifier” are used interchangeably herein.
An entity-specific address may identify an entity included in the entity to which the address is specific. Such as an address is said to be a “scoped”. An entity-specific address may identify an entity external to the entity to which the address is specific. Such as address is said to be “scope-specific”. The fact that an address is entity-specific does not define a scope for the address.
A portion of a network is a type of entity. A type of entity-specific address space described herein is a scope-specific address space. As used herein, a “scope-specific address space”, specific to a particular region of a network, is an address space defined for the particular network region, where an address in the scope-specific protocol address operates as an identifier, according to a network protocol, of a protocol endpoint in a node outside of the particular region when processed in the context of a node in the particular region. The region is indicated by the span of an indicated scope. The terms “region” and “zone” are used interchangeably herein. An address from a scope-specific address space is referred to herein as a “scope-specific protocol address”. An address is “scope-specific” in that what protocol endpoint it identifies depends on the region to which it is specific. Another address having the exact same form and content may identify a different protocol endpoint when in an address space that is specific to another region. A protocol address in a scope-specific address space serves as an identifier in the context of a node in a region to which the scope-specific address space is “specific” as defined by an association of the address space and the region indicated by the scope. Without knowledge of the particular region to which a scope-specific address space is specific, what a scope-specific protocol address in the scope-specific address space identifies is indeterminate. The terms “scope-specific protocol address” and “scope-specific protocol identifier” are used interchangeably herein. Types of scope-specific address spaces indicating exemplary spans include site-specific, LAN-specific, subnet-specific, city-specific, business-specific, and node-specific.
For a network protocol, an address in a scope-specific address space serves as an identifier of a protocol endpoint in a node. Data may be received via the protocol endpoint from a network via one or more network interfaces that operatively couple the node to the network. Data may be sent via the protocol endpoint to transmit over the network via the one or more network interfaces in the node. Since a protocol endpoint of a network protocol is included in a node and is accessible via a network via a network interface, a protocol address identifying the protocol endpoint also identifies the node and identifies a network interface of the node.
As used herein, a “node-specific address space” is a scope-specific address space defined for a specific node in a network, where the addresses in the node-specific address space operate as identifiers of nodes and/or network interfaces in the network when processed in the context of the specific node. An address from a node-specific address space is referred to herein as a “node-specific address”. An address is “node-specific” in that what it identifies depends on the node to which is defined as specific. Another address having the exact same form and content may identify a different node when in an address space specific to another node. Addresses in a node-specific address space operate as identifiers in the context of a node to which they are “specific” as defined by the specific association of the address space and the node. Without knowledge of the node to which a node-specific address space is specific, addresses in the node-specific address space are indeterminate. The terms “node-specific address” and “node-specific identifier” are used interchangeably herein. A node-specific address space is a type of scope-specific address space.
The term “node” is defined above. Note that an identifier of a network interface in a network also identifies a node that includes the network interface. Thus, a network interface-specific address is also a node-specific address. Network interfaces in a node may have their own respective network interface-specific address spaces that are also node-specific. The network interface-specific address spaces may be combined to form a node-specific address space and/or may be managed as separate address spaces. The adjectives “node-specific” and “network interface-specific” may be used interchangeably.
A scope-specific identifier differs from a scoped address. Scoped addresses are described in RFC 3007, RFC 3513, and further described in application Ser. No. 11/962,285, by the present inventor, filed on 2007 Dec. 21, entitled “Methods and Systems for Sending Information to a Zone Included in an Internet Network”. A scoped address space is shared by nodes in a given scope. While a link-local scoped address is specific to a particular node, a link-local scoped address simply identifies a network interface component local to the particular node. A loop-back internet address is specific to a node as well. Neither link-local scoped addresses nor loop-back addresses identify one node to another. As such, neither serves as a node-specific identifier as defined above.
A “scoped address” is described by RFC 3513 and RFC 3007 as an identifier that, in a particular region of a network, serves as a protocol address of a network interface and/or a node in the particular region. The extent of the particular region is referred to as the scope of the region and thus the scope within which the identifier serves as a protocol address. A particular region included within a scope is indicated by its span. A scoped address is a valid protocol address only within a particular region as indicated by the address's indicated scope. Examples of scope indicators include node-scope where identifiers are valid only to a single node in the indicated span, LAN-scope where identifiers are valid for nodes in the span of a particular LAN, and subnet-scope where identifiers are valid only for nodes in a particular subnet. RFC 3513 currently defines support for link-local scope, site-local scope, and global scope. A data unit transmitted with a scoped address should not be delivered to node that does not have a network interface in the span indicated by the scope.
“Path information” is any information that identifies a network path, such as a hop path, for data transmitted via one or more specified network protocols. Path information may be identified by identifying network interfaces, NICs, nodes, and/or hops included in a network path. “Address information” is any information that identifies a protocol address that, for a network protocol, identifies a protocol endpoint. Address information may identify a unicast protocol address for a network protocol. In identifying a protocol endpoint, a protocol address identifies a node and a network interface.
Those skilled in the art will understand upon reading the descriptions herein that the subject matter disclosed herein is not restricted to the network protocols described and/or their corresponding OSI layers. For ease of illustration, the subject matter is described in terms of protocols that correspond to OSI layer three, also referred to as network layer protocols, in general. Particular descriptions are based on versions of the Internet Protocol (IP). Address information may identify one or more protocol addresses. Exemplary protocol addresses include IP addresses, IPX addresses, DECNet addresses, VINES Internet Protocol addresses, and Datagram Delivery Protocol (DDP) addresses, HTTP URLS, TCP port and IP address pairs, and the like.
The term “metric space”, as used herein, refers to a set, as defined in mathematics, where a distance between elements of the set is defined according to a metric. Metric spaces defined in Euclidean geometry are well-known examples. Those skilled in the art of metric spaces, such as Euclidian spaces, will appreciate that a one-to-one mapping may be determined and/or otherwise identified for mapping addresses from a first coordinate space having a first origin for a metric space to addresses from a second coordinate space having a second origin in the metric space. Given a mapping rule between a first scope-specific address space and a second scope-specific address space and a mapping between the second scope-specific address space and a third scope-specific address space based on a third coordinate space identifying a third origin in the metric space, a mapping from the first coordinate space to the third coordinate space may be determined. A mapping between coordinate spaces for a metric space may be include, for example, coordinate shift and/or a rotation, for example. The mapping may be pre-specified and accessible to the nodes in one or both address spaces. Mapping between locations in a number of different metric spaces is well known in mathematics. For example, a top half of the surface of sphere may be mapped to a plane. Some will further appreciate that some metric spaces may be mapped to other metric spaces. Some of these mappings are one-to-one and/or onto.
As used herein, the term “software component” refers to any data representation that includes and/or may be translated to include one or more instructions executable by a processor. A software component may optionally include associated data that does not represent an instruction executable by a processor.
Methods, Systems, and Operation:
Some components, illustrated in the drawings are identified by numbers with an alphanumeric suffix. A component may be referred to generically in the singular or the plural by dropping a suffix of a portion thereof of the component's identifier.
An application, such as an application 30201 operating in an operating environment 30200 of a node 30102, may exchange data with another node 30102 by interoperating with one or more components of a corresponding network stack. In
Transport layer protocols supported by connectionless component 30205 and by connection-oriented component 30207 generate transport layer data units to include data received from an operatively coupled application to deliver the data via the data units according to a network layer protocol to a transport layer protocol endpoint in another node 30102. Analogously, data sent via an application in another node via a transport layer component may be received according to the network layer protocol by a compatible transport layer component, such as a connection-oriented component 30208 and/or by a connectionless component 30205, to deliver via a socket to an application operating in an operating environment 30200 in the receiving other node 30102.
One or more link layer protocols may be included in communicatively coupling a source node 30102 and a destination node 30102 via a network path that includes one or more path nodes 30104 as illustrated in
For ease of illustration, the description herein focuses on IP networks and protocols in the TCP/IP suite due to their wide use and because they are well-known in the art. Those skilled in the art will understand that the scope of the subject matter described is not limited to IP networks. For example, link layer protocols and networks are considered to be within the scope of the subject matter of this disclosure.
With respect to
A network layer component 30209 operating in a node 30102 may communicate with one or more nodes 30102 over a LAN, a link, and/or a network of networks such as an intranet or the Internet. A network layer component 30209 in the node 30102 may receive transport layer data units, for example, formatted as TCP packets from a connection-oriented layer component 30207 and/or transport layer data units formatted as UDP packets from a connectionless component 30205 illustrated in
Analogously, the network layer component 30209 interprets data, received from a link layer component 30211 in the node 30102, as IP protocol data and detects IP packets in the received data. The network layer component 30209 may strip off IP layer specific data and transfer the payload of one or more IP packets to the connection-oriented layer component 30207 and/or to the connectionless component 30205 to process as transport layer data units according to a particular transport layer protocol.
As described above,
In transmitting data from a source protocol endpoint in a source node 30102 to a destination protocol interface in a destination node 30102, the data is processed by a sequence of nodes in a network path that communicatively couples the source node 30102 and the destination node 30102. A node in the network path that is currently processing the data to send it to the destination 30102, is referred to herein as a “current node” with respect to the data or more precisely referred to as a “current path node” when the current node is a path node. A node in the network path that has previously transmitted the data being processed by the current node is referred to herein as a “previous node”. A node in the network path that has not received the data being processed by the current node is referred to herein as a “next node”. For ease of description, “data” refers to data sent in a data unit via a protocol endpoint in the source node being processed by a path node, current to the data, for transmitting to a next node in a network path to an identified destination node. As such, a source node 30102 may be a one of a current node and a previous node with respect to particular data. A path node 30104 may be one of a current node, a previous node, and a next node with respect to particular data. A destination node 30102 may be one or a next node and a current node with respect to particular data.
In another aspect, a path node 30104 may include and/or otherwise may be included in an operating environment 30200 including at least a some of the component illustrated in
A network interface in a path node 30104 may receive data communicated from a source node 30102 via a previous network path included in a network in a system 30100. One or more network paths may exist for receiving the data. A source node 30102 may be and/or otherwise may include a desktop PC, a notebook, a server, or a handheld computing device serving as a gateway, bridge, or other network relay device.
A path node 30104 may be configured for receiving data from a source node 30102 and for transmitting the received data to a destination node 30102 via a specified network protocol. For example, a path node 30104 may receive and transmit a data unit at a link layer as performed by an Ethernet bridge and a multiple protocol labeling switch (MPLS). Further, a path node 30104 may receive and transmit a data unit at a network layer as performed by an Internet protocol (IP) router. Still further, a path node 30104 may receive and transmit a data unit at an application layer, as defined above.
Accordingly, data from a source node 30102 may be included in and/or may include data formatted according a link layer protocol, a network layer protocol, and/or an application layer protocol. In-data logic may be configured according to a network layer protocol, a link layer protocol, and/or an application layer protocol.
In addition to the protocols described above, protocols corresponding to layers in the OSI model above the transport layer may be included in communicating via a network. The term “application protocol” as used herein refers to any protocol or combination of protocols that correspond to one or more layers in the OSI reference model above the transport layer. Programs and executables operating in operating environment 30200 may communicate via one or more application protocols. Exemplary application protocols include a hypertext transfer protocol (HTTP), various remote procedure call (RPC) protocols, various instant messaging protocol, email protocols, and various presence protocols.
Data exchanged between nodes in a network 30100, in
A network protocol is defined by one or more formatting rules and/or a vocabulary referred to as a schema. The schema defines valid data units to exchange between and/or among protocol endpoints defined by the respective network protocol. A network protocol also specifies and/or otherwise is compatible with one or more address spaces for identifying protocol endpoints for exchanging data. The terms “identifier space” and “address space” are used interchangeably herein. For example, various versions of hypertext transfer protocol (HTTP) specify a format for HTTP uniform resource locators (URL). HTTP specifies a location in a HTTP header that identifies a URL as an identifier or address from the HTTP address space that identifies both a resource and recipient of a HTTP data unit. The transmission control protocol (TCP) specifies a format and vocabulary for a TCP header including a destination protocol endpoint field for including what the TCP refers to as a destination port number that, when combined with a destination protocol address from an IP packet, identifies a transport layer protocol endpoint of a receiver of data included in a TCP data unit. A sending endpoint is similarly identified by a source port number included in a source protocol endpoint field of a TCP data unit and a source protocol address from an IP data unit.
Other exemplary address spaces that identify protocol endpoints in various protocols include an email address space identifying a protocol endpoint for the simple mail transfer protocol (SMTP), a telephone number address space for various telephony protocols, instant message address spaces for various instant message protocols, and media access control (MAC) addresses for various link layer protocols, to name just a few examples.
In delivering data across a network between protocol endpoints, addresses from address spaces of the various protocols at the various layers may be translated and/or otherwise mapped between the various layers of a network stack. For example, a unicast IP address in an IP packet may be mapped to link layer addresses for the various links the IP packet is transported across in a network path via a path node 30104 between a source node 30102 sending the data via the IP protocol and a destination node 30102 receiving the data. Addresses at the various layers are assigned from a suitable address space of network protocols of the respective layers.
Since addresses from address spaces at various layers of a network stack are often not suited for remembering and/or identifying by users, an address space of symbolic identifiers or names may be used to provide aliases for addresses in an address space identifying protocol endpoints corresponding to a protocol supported by a layer of a network stack. The domain name space is a well-known identifier space of names for identifying nodes and/or network interfaces as protocol endpoints of the IP protocol in the Internet, private internets, and intranets.
As shown, the method 30400 includes receiving a first protocol address that identifies a destination protocol endpoint of a network protocol and receiving a second protocol address that identifies a destination protocol endpoint of the network protocol. See operation 30402. Additionally, the method 30400 includes storing the first protocol address in a first address field of a first data unit of the network protocol, wherein the first protocol address has a first length when stored in the first address field and the first address field is defined by the network protocol. See operation 30404. Also, the method 30400 includes storing the second protocol address in a second address field of a second data unit of the network protocol, wherein the second protocol address has a second length when stored in the second address field and the second address field is defined by the network protocol. See operation 30406. Further, the method 30400 includes sending data in a first payload of the first data unit via a network for delivery to a destination node that includes the destination protocol endpoint identified by the first protocol address. See operation 30408. Still further, the method 30400 includes sending data in a first payload of the first data unit via a network for delivery to a destination node that includes the destination protocol endpoint identified by the first protocol address. See operation 30410.
More illustrative information will now be set forth regarding various optional architectures and features with which the foregoing framework may or may not be implemented, per the desires of the user. It should be strongly noted that the following information is set forth for illustrative purposes and should not be construed as limiting in any manner. Any of the following features may be optionally incorporated with or without the exclusion of other features described.
An address field in a data unit may have a fixed length as specified by a network protocol. See for example
For example, the length of an address field may be determined based on the length of a protocol address stored and/or to be stored in the address field. Such an address field may have a length that is the same as the length of the protocol address stored in the address field. In another aspect, an address field may be longer than the protocol address of the protocol address stored in the address field. Protocol addresses stored in address fields and the respective address fields may have different requirements as specified by a network protocol. For example, address fields may be specified to end on a byte boundary while a protocol address stored in the address field may end on any bit boundary. A protocol may specify that a particular padding value be stored in an unused portion of an address field in a data unit of the network protocol.
An address separator field 30702d includes a series of one-valued bits and zero-valued bits. A change from a one-value to a zero-value and vice versa may indicate a boundary that separates protocol endpoint identifiers and/or interface identifiers. An address separator field 30702d1 includes one zero-valued bit followed by four one-valued bits. The zero-valued bit may be defined to indicate that a first network interface in a first hop identifier is one bit long with a corresponding position in the address data field 30704d.
Note that the address separator field 30702d6 does not identify a pair of identifiers and is similar to address separator fields 30702c in
See application Ser. No. 11/962,285, by the present inventor, filed on 2007 Dec. 21, entitled “Methods and Systems for Sending Information to a Zone Included in an Internet Network” for a description of addresses having outside scope and/or inside scope and processing of such addresses. A third address data field 30704e3 corresponding to a third address separator field 30702e3 may include a pair of identifiers as described with respect to
As described above an address field in a data unit of a network protocol may have a length that differs from an address field in another data unit of the network protocol. Alternatively, an address field may be specified for a network protocol that has a fixed length in data units of the network protocol, but may allow protocol addresses respectively stored in the address fields to have various lengths. A network protocol may specify that an address field may be stored contiguously in a data unit of the network protocol. Alternatively or additionally, a network protocol may specify that an address field be included in a data unit of the network protocol in a contiguous manner. Analogously, a network protocol may specify that a protocol address may be stored contiguously in an address field of a data unit of the network protocol. Alternatively or additionally, a network protocol may specify that a protocol address be included in an address field in a data unit of the network protocol in a contiguous manner.
A network protocol may specify conditions for allowable lengths of address fields and/or protocol address in data units of the network protocol. For example, a network protocol may be specified to allow address field lengths to be even numbers in bits or bytes. That is, lengths of address fields may be specified to differ by a length that is divisible by a particular number or particular numbers.
A first protocol address, having a first length, may be included in a first data unit to send data to a protocol endpoint of a network protocol in a destination node. A second protocol address, having a different length, may be included in a second data unit to send data to a protocol endpoint of the network protocol in the same destination node. The protocol endpoint identified by the second protocol address may be the same protocol endpoint identified by the first protocol address or may be a different protocol endpoint. For example, the first data unit be included in sending data to the destination node via first network path and the second data unit may be included in sending data to the destination node via a second network path. The data sent via the first network path and the data sent via the second network path may be sent by a same source node or a different source node.
Analogously, data sent in a payload of the first data unit may be received by a current node via a first path node and the data in a payload of the second data unit may be received by the current node via a second path node. The data in the first payload may be sent from a first source node and the data in the second payload may be sent from a second source node. In another aspect, the data in the first payload and the data in the second payload may be sent from a same source node. Further, the data in the first payload may be sent from a current node via a first path node and the data in the second payload may be sent by the current node via a second path node.
In another aspect, the protocol endpoint identified by the first protocol address may be in first destination node and a protocol endpoint identified by the second protocol address may be in a second destination node. Data sent in a first payload of the first data unit may be from a first source node and the data in a second payload of the second data unit may be from a second source node. In another aspect, the data in the first data unit and the data in the second data unit may be sent from a same source node
Analogously, data in the first payload may be received by a current node via a first path node and data in the second payload is received by the current node via a second path node. Further, the data in the first payload may be from a first source node and the data in the second payload may be from a second source node. In another aspect, the data in the first payload and the data in the second payload are from a same source node.
As shown, the method 30900 includes receiving, by a path node and based on a first portion of a destination address, a first in-data unit in a flow of data units transmitted from a source node to a destination node, where in the destination address identifies the destination node and wherein the first in-data unit includes a second portion of the destination address. See operation 30902. Additionally, the method 30900 includes receiving, based on the first portion, a second in-data unit in the flow, wherein the second in-data unit does not include the second portion. See operation 30904. Also, the method 30900 includes sending, to a next node via the second portion, a second-out data unit that includes second data received in the second in-data unit. See operation 30906.
In
The path identifier may be received by the path node 30104c1 from the first node 30102c1 in the data unit with the address portion 0, received by the first node 30102c1 from the first path node 30104c2, may be negotiated by the two nodes, and/or may be received from a different node which for example may include network management logic, topology management logic, and/or routing logic.
In an aspect, the first node 30102c1 may send a second data unit to the first path node 30104c1. The header of the data unit may include the path identifier described above in an id field 301006b as illustrated in
With the associations accessible to the respective path nodes 30104c, the first node 30102c1 may send data to the second node 30102c2 by sending the data in a data unit to the first path node 30104c1. The data unit may include the path identifier shared by the first node 30102c1 and the first path node 30104c1. The first path node 30104c2 may identify the next portion, 0, of the protocol address of the second node 30102c2 based on the path identifier and the association between the protocol address 1.0 and 0. The first path node 30104c1, in response, may send the data in a data unit addressed to the third path node 30104c3 along with the path identifier shared by the first path node 30104c1 and the third path node 30104c3. The third path node 30104c3 and the seventh path node 30104c7 may similarly and subsequently relay the data to the second node 30102c2 based on a shared path identifiers and stored associations analogous to those just described.
Alternatively or additionally, the second data unit in the previous paragraph may be received prior to receiving the first data unit. For example, the first node 30102c1 may send a data unit to the third path node 30104c3 that includes the protocol address 0 and a next portion 1.0 along with a path identifier or other suitable correlator. A data unit subsequently received and/or a data unit previously received via the protocol address 0 that includes the correlator may be processed by a routing component 30210, in
Note that the various address portions associated by nodes in a network path may be the same length and/or different lengths as specified for an address space of a network protocol.
As shown, the method 301200 includes receiving, by a path node via a first network interface, data for delivering via a network to a destination node from a source node, wherein the data is received in a data unit, of a network protocol, that includes a destination address field defined by the network protocol to identify a destination protocol address that identifies the destination node and that identifies a first protocol address that identifies the path node. See operation 301202. Additionally, the method 301200 includes identifying, in the destination address field, a second protocol address of a node that communicatively couples the path node and the destination node. See operation 301204. Also, the method 301200 includes transmitting, based on the second protocol address, the data for delivery to the destination node. See operation 301206.
With respect to
At the first node 30102a1, a packet generator component 30204 in an operating environment 30200 of the first node 30102a1 and/or an address handler component 30202 operating in the first node 30102a1 may set and/or otherwise detect a value in the address separator field 30702a that indicates that a first address field 30704a1 has a zero length. The address data field 30704a, thus, constitutes a second address field at the first node 30102a1 and identifies the first-second protocol address that may be set and/or otherwise detected by a path separator component 30218.
An instance or analog of an execution environment 30200, in
At the second node 30102a2 a data unit including the data from the first node 30102a1 may include a value, set and/or detected by a separator component 30218 of the second node 30102a2, in an address separator field 30702a that indicates that the address data field 30704a includes only a first address field 30704a1 identifying 2.2.3.3 as the first protocol address.
As the data from the first node 30102a1 is transmitted from node to node in the network path the value represented in an address separator field 30702a in an address data field 30704a in a data unit including the data or a portion thereof may be adjusted by respective path separator components 30218 of the nodes in the network path to identify a protocol address in a suitable address space for the respective nodes.
As shown, the method 301400 includes receiving, by a path node via a first network interface, data to deliver to a destination node from a source node via a network having a network topology included in a metric space, wherein the data is received in a data unit that includes an address field that identifies at least one of a source protocol address that identifies, relative to a path node protocol address that identifies a relay location of the path node in the metric space, the source node and a path node protocol address that identifies, relative to a source protocol address that identifies a source location of the source node in the metric space, the path node. See operation 301402. Additionally, the method 301400 includes detecting in an address field in the data unit second address information that identifies at least one of a destination protocol address that identifies, relative to the path node protocol address, the destination node and a path node protocol address that identifies, relative to a destination protocol address that identifies a destination location of the destination node in the metric space, the path node. See operation 301404. Also, the method 301400 includes sending, via the least one of the destination protocol address and the path node protocol address, the data for delivery via the network to the destination node. See operation 301406.
In an aspect, a current address space may include identifiers that identify respective locations, in a multi-dimensional metric space, that is defined based on a plurality of axes that intersect at a current-origin location in the metric space that represents a node in the current scope-specific address space. A network interface of the node at the current-origin location may be identified based on an axis in the plurality of axes. The current-next protocol address may be detected relative to a current-origin address that, in the current scope-specific address space, identifies the current-origin location in the metric space, wherein the current-next protocol address identifies a next location in the metric space relative to the current-origin location and the next location represents the next node.
In related aspect, a current path node, in a network path for transmitting data from a source node to a destination node, may be in a current network region that has a current scope-specific address space. The current scope-specific address space may include an origin address, such as address “300.300.300.300”, that identifies a network interface of a node in the network identifying an origin node and/or an origin network interface. Protocol addresses in the current scope-specific address space that identify other network interfaces and/or nodes may be defined relative to the origin address based on a specified mapping rule that is defined based on a relationship between the origin node and other network interfaces and/or nodes in the network. The mapping rule may be based on a metric and represented in a network topology of the network.
A mapping rule between a current node-specific address space of a current node and next scope-specific address space specific to a next node may be determined based on an current origin protocol address in the current scope-specific address space, a current-next protocol address in the next scope-specific address space that identifies the current node, and a protocol address in the current scope-specific address space of an origin network interface and/or origin node in the next network region.
The mapping rule may specify a coordinate shift and/or a rotation about an axis, for example. The mapping may be pre-specified and accessible to the current node. In another aspect, the current node may determine the mapping based on detected relationships between pairs of protocol addresses respectively from the two scope-specific addresses spaces of the current node and the next node, respectively, where a protocol address from each of the address spaces that identifies a same node is known to the current node.
Exemplary metric spaces include Euclidean spaces, non-Euclidean spaces, geo-spaces, and other geometric spaces. A Cartesian coordinate system is an exemplary address space for a Euclidean space. Another example of a geometric address space is a geospatial address space such as used currently in geo-location services. Networks have topologies that may be represented in a geo-space including locations addressed via a geometric address space.
As shown, the method 301600 includes receiving, by a path node via a first network interface, data to deliver to a destination node from a source node via destination network path included in communicatively coupling the source node and the destination node, wherein the data is received in a data unit that includes an address field that at least one of includes a first path node identifier identifying a first path node in a first hop included in communicatively coupling the source node and the path node and includes a first hop identifier identifying the first hop that includes a first pair of nodes. See operation 301602. Additionally, the method 301600 includes detecting in the data unit an address field that includes at least one of a second path node identifier identifying a second path node in a second hop included in communicatively coupling the path node and the destination node and a second hop identifier identifying the second hop that includes a second pair of nodes. See operation 301604. Also, the method 301600 includes sending, based on the second address information, the data via the second network interface for delivery to the destination node. See operation 301606.
In
A first node 30102c1 may identify a second node 30102c2 by a first-second protocol address that, in a first scope-specific address space specific to a first region 30110c1 including the first node 30102c1, identifies the second node 30102c2. The first-second protocol address may include and/or otherwise may be based on a sequence of hop identifiers 0.1.3.2.1. Note that other network paths are illustrated for transmitting data from the first node 30102c1 to the second node 30102c2 and may also be and/or otherwise may identify protocol addresses in the first scope-specific address space that identify the second node 30102c2 to nodes in the first region 30110c1.
The hop identifiers, 0.1.3.2.1, may be represented in an address representation 30700c in an address field in a data unit for sending data from the first node 30102c1 to the second node 30102c2. The hop identifier 301 in the address identifies a fifth hop 30108c5 that includes the second path node 30104c2 and a third path node 30104c3. The hop identifier 303 in the address identifies a hop that includes the third path node 30104c3 and a fifth path node 30104c5. The hop identifier 302 in the address identifies a hop that includes the fifth path node 30104c5 and the seventh path node 30104c7. The second identifier 301 in the address identifies a first hop 30108c5 that includes the second path node 30104c2 and the seventh path node 30104c7.
As described in the previous paragraph, a hop may be assigned an identifier that is shared by the pair of nodes in the hop. Thus, a sequence of hop identifiers may serve as a scope-specific address in one scope-specific address space when processed in one order of the sequence and may serve as another scope-specific address specific to another node when processed according to another order of the sequence. Any of the address types illustrated in
As shown, the method 301800 includes receiving, by a second node, a data unit that includes data sent from a source node to a destination node identified by destination address field of the data unit that identifies a destination protocol address, of the destination node, for transmitting the data from the source node to the destination node via a network having a network topology included a metric space, wherein the data unit is received via a first network interface that is identified by first path information, in the destination address field, that identifies a first network path relative to one of a source origin address that, in a source address space of the source node, identifies a source location of the source node in the metric space and a second origin address that, in a second address space of the second node, identifies a second location of the second node in the metric space. See operation 301802. Additionally, the method 301800 includes detecting second path information, in the destination address data field, that identifies a second network path relative to one of the second origin address and a destination origin address that, in a destination address space of the destination node, identifies a destination location of the destination node in the metric space. See operation 301804. Also, the method 301800 includes transmitting, based on the second path information, the data for delivery to the destination node. See operation 301806.
As described with respect to
As shown, the method 302000 includes receiving, via a network and based on a first hop identifier that is in a destination address field in a data unit of a network protocol and that identifies a first communicative coupling between a first pair of nodes in a network path from a source node to a destination node, a data unit, wherein the first hop identifier includes a first NIC identifier of a first NIC included in the first communicative coupling. See operation 302002. Additionally, the method 302000 includes detecting, in the destination address, a second hop identifier that identifies a second communicative coupling between a second pair of nodes in the network path. See operation 302004. Also, the method 302000 includes identifying a second NIC identifier identifying a second NIC included in the second communicative coupling. See operation 302006. Further, the method 302000 includes sending, based on the second hop identifier, the data for forwarding, via the second NIC, between the second pair in the network path to the destination node. See operation 302008.
In
As shown, the method 302200 includes receiving, from a previous node by a current node via a previous network interface operatively coupling the current node to a network, data in a data unit of a network protocol, wherein the data unit is received from the previous node based on an address field included in the data unit to identify a protocol endpoint of the network protocol. See operation 302202. Additionally, the method 302200 includes detecting a previous-next protocol address received in the address field and that, in a previous scope-specific address space specific to a previous network region including the previous node, identifies a next node. See operation 302204. Also, the method 302200 includes determining, based on the previous-next protocol address, a next network interface communicatively coupling the current node to a next network region. See operation 302206. Further, the method 302200 includes sending, via the next network interface, the data to the next node by the current node. See operation 302208.
In
As shown, the method 302400 includes detecting, in a data unit that is specified according to a network protocol and that includes data from a source node for transmitting via a network to a destination node, a source-destination protocol address that identifies for the network protocol the destination node to the source node. See operation 302402. Additionally, the method 302400 includes detecting, in the source-destination protocol address, a current-next protocol address that for the network protocol identifies, to a current node that has received the data, a next node that has not yet received the data. See operation 302404. Also, the method 302400 includes sending, by the current node based on the current-next protocol address, the data to the destination node via the next node, wherein the next node is not the destination node. See operation 302406.
As shown, the method 302600 includes receiving, by a path node via a first network interface, data for delivering to a destination node from a source node via destination network path included in communicatively coupling the source node and the destination node, wherein the data is received in a data unit that for a network protocol includes an address field that includes at least one of a first path node identifier identifying a first path node in a first hop and a first hop identifier identifying the first hop that includes a first pair of nodes in a first portion of the destination network path and wherein the first hop is included in communicatively coupling the source node and the path node. See operation 302602. Additionally, the method 302600 includes detecting, in the address field, at least one of a second path node identifier identifying a second path node in a second hop and a second hop identifier identifying the second hop that includes a second pair of nodes in a second portion of the destination network path, wherein the second hop is included in communicatively coupling the path node and the destination node. See operation 302604. Also, the method 302600 includes identifying, based on the second address field, a second network interface included in communicatively coupling via the second portion the path node and the destination node. See operation 302606. Further, the method 302600 includes sending the data via the second network interface for delivery to the destination node. See operation 302608.
A hop identifier in a protocol address may include at least one of the first node and the second node. The hop identifier may include a network interface identifier of a network interface of a node in the hop. In network 30100b in
A protocol address that for a network protocol identifies a second node to a first node may be defined by a network protocol to include a network interface identifier identifying a network interface included in communicatively coupling a first node and a second node. With respect to
As shown, the method 302800 includes detecting data from a component of a source node for sending to a destination node via a network path in a network, wherein the network path includes the source node and the destination node identified for a network protocol by a destination protocol address. See operation 302802. Additionally, the method 302800 includes Identifying, in the destination protocol address, a next protocol address of a next node in the network path that is not the destination node. See operation 302804. Also, the method 302800 includes sending, based on the next protocol address, the data to the next node. See operation 302806.
As shown, the method 303000 includes detecting, in a data unit included in sending data via a network protocol from a source node to a destination node via a network path that includes the source node and the destination node, an address field specified according to the network protocol to include a source protocol address. See operation 303002. Additionally, the method 303000 includes identifying, in the address field, a previous portion for identifying a previous protocol address identifying a previous node in the network path that has received the data and a next portion for identifying a next protocol address identifying a next node in the network path that has not received the data. See operation 303004. Also, the method 303000 includes sending, based on the next portion, the data via the network for transmitting to the next node. See operation 303006.
With respect to
A destination-source protocol address, that in a destination scope-specific address space specific to a destination network region that includes the destination node, identifies the source node may be identified. A data unit may include separate address representations for destination address information and source address information as, for example, current IP packet headers are specified. Alternatively, a data unit such as an IP packet and or an Ethernet frame may include an address representation that identifies source address information in the context of one address space specific to a node, in a region, in a network path traversed by the data unit and identifies destination address information to another node, in another region in the network path. The protocol addresses may have variable lengths.
With respect to
A sequence of hop identifiers based on interface identifiers may serve as a scope-specific address in one scope-specific address space when processed in one order of the sequence and may serve as another scope-specific address specific to another node when processed according to another order of the sequence. In
As has been described above, a protocol address that for a network protocol identifies a second node to a first node may include a plurality of hop identifiers in an identifiable first order and in an identifiable second order, wherein the protocol address includes the plurality of hop identifiers in the first order and a second-first protocol address, that identifies the first node to the second node, includes the plurality of hop identifiers in the second order. At least one of the first order and the second order may be identified by sequence information defined by a schema of the network protocol in the data unit. The sequence information may be represented separately from the plurality of hop identifiers.
As shown, the method 303200 includes receiving a data unit that according to a network protocol includes an address field identifying a source-destination protocol address that identifies at least one of a source node and a destination node. See operation 303202. Additionally, the method 303200 includes detecting next hop information in the data unit that identifies a first protocol address, in at least a portion of the source-destination protocol address, that identifies a first node in a network path, in a network, included in communicatively coupling the source node and the destination node. See operation 303204. Also, the method 303200 includes changing the next hop information to identify a second protocol address, in at least a portion of the source-destination protocol address, that identifies a second node in the network path. See operation 303206. Further, the method 303200 includes sending the changed next hop information and data, received in the data unit, for transmitting, via the network path, to the destination node. See operation 303208.
A protocol address that for a network protocol identifies a second node to a first node may include first hop information identifying a first hop including a first pair of communicatively coupled nodes included in communicatively coupling the first node and the second node. The sequence, 0.1.3.2.3.2, described in the previous paragraph includes the hop identifier 301 which identifies a fifth hop 30108c5 in the network 30100c. The first hop 30102c5 includes a fourth path node 30104c4 and a second path node 30104c2, included in a network path that communicatively couples the first node 30102c1 and the eleventh node 30102c11.
As shown, the method 303400 includes receiving, by a path node via a first network interface, data, for delivering via a network to destination node form a source node, in a data unit of a network protocol and that includes an address field identifying a first unicast protocol address, of the network protocol, that identifies the path node, wherein the address field is defined by the network protocol to identify a destination unicast protocol address that identifies the destination node. See operation 303402. Additionally, the method 303400 includes receiving, by a path node via a first network interface, data, for delivering via a network to destination node form a source node, in a data unit of a network protocol and that includes an address field identifying a first unicast protocol address, of the network protocol, that identifies the path node, wherein the address field is defined by the network protocol to identify a destination unicast protocol address that identifies the destination node. See operation 303404. Also, the method 303400 includes sending the data via a second network interface for delivery to the destination node. See operation 303406.
As shown, the method 303600 includes detecting data, by a current node in a network path in a network, for sending from a source node to a destination node via the network path, wherein the network path includes the source node and the destination node. See operation 303602. Additionally, the method 303600 includes identifying a next protocol address that, in a current node-specific address space specific to the current node, identifies a next node in the network path for a network protocol included in sending the data to the destination node. See operation 303604. Also, the method 303600 includes sending, via the network protocol and based on the next protocol address, the data to the next node by the current node. See operation 303606.
A protocol address that for a network protocol identifies a second node to a first node may include an identifier of a network path included in communicatively coupling a first node and a second node. For example, with respect to
The description above with respect to
As described above, sending data via a scope-specific address may include sending the data via a sequence of hops in a network path included in communicatively coupling a source node and a destination node. The source-destination protocol address may include a plurality of hop identifiers respectively identifying the hops in the sequence. They data may be sent via a first path node in a network path communicatively coupling the source node and the destination node. In an aspect, the first path node is not included in the source network region and the first path node is not included a destination network region that includes the destination node. The source-destination protocol address may include a source-first address that, in the source scope-specific address space and for the network protocol, identifies the first path node to the source node. The source-destination protocol address may include a first hop identifier that identifies a first hop in the network path, where the first hop includes at least one of the source node and the first path node
Sending data in a data unit by a first node may include detecting, in the data unit, address separating information specified according to the network protocol for detecting at least one of a first-next protocol address information and a next-first protocol address information. The address separating information may be updated for identifying, by a next node included in communicatively coupling the first node and the second node, the at least one of the first-next protocol address information and next-first protocol address information in the address information, wherein the next-first protocol address information includes information for identifying the first node.
A protocol address, that for a network protocol identifies a second node to a first node, may include a first path node protocol address that, in the first scope-specific address space specific to the first region, identifies a first path node included in a first network path included in communicatively coupling the first node and the second node.
Additionally or alternatively, a protocol address, that for a network protocol identifies a second node to a first node, may include a second path node protocol address that, in the path node scope-specific address space specific to a path node region that includes the path node, identifies the second node. The path node is included in a network path that communicatively couples the first node and the second node Further, identifying a protocol address that for a network protocol identifies a second node to a first node may include identifying, based on the protocol address, the first path node protocol address and based path node second protocol address
Sending data from a first node to a second node may include sending the data via a path node in a network path communicatively coupling the first node and the second node. The path node, in an aspect, is not included in a first network region that includes the first node and the path node is not included a second network region that includes the second node. The protocol address may include a first path node address that, in the first scope-specific address space and for the network protocol, identifies the path node to the first node and the protocol address includes a second path node address that, in a path-node-scope-specific address space specific to a path node network region that includes the path node, identifies the second node to the first path node for the network protocol
Further, a protocol address that for a network protocol identifies a second node to a first node may include a first hop identifier that identifies a first hop in a network path. The first hop may one or both of the first node and the first path node. A first hop identifier may be assigned from the first scope-specific address space to identify the first hop in response to a negotiation between the first node and another node in the first hop. A protocol address that for a network protocol identifies a second node to a first node may include a second hop identifier that identifies a second hop in the network path, wherein the second hop includes at least one of the second node and the first path node
A protocol address that for a network protocol identifies a second node to a first node may include a hop identifier that identifies a hop in the network path. The hop identifier may, in a scope-specific address space specific to a network region that includes one of a pair of nodes in the first hop, identify the other one of the pair of nodes. The hop includes a first hop node and a second hop node that are communicatively coupled via a first network interface in the first hop node and via a second network interface in the second hop node. The first hop identifier may include at one or more of a first network interface identifier identifying the first network interface and a second network interface identifying the second network interface to at least one of the first hop node and the second hop node
As described various types of protocol addresses may conform to various schemas defining rules for formatting valid protocol addresses and/or defining vocabularies specifying valid content of a protocol address. Given a current node in a network path for transmitting data from a source node to a destination node, the current node may identify a next protocol address and/or a previous protocol address that are scope-specific protocol addresses according to various aspects as described above, and their analogs and extensions.
A next protocol address and/or a previous protocol address may be determined and/or otherwise identified based on one or more of a schema of one or more of a destination protocol address and/or a source protocol address identified in an address information of a data unit, a schema of a scope-specific hop identifier, a mapping between two or more of the schemas or portions thereof of two or more respective scope-specific address spaces, relationships between the nodes to which the protocol addresses are specific, relationships between the scope-specific address spaces of the protocol addresses, and relationships between the nodes in a network that includes them. Some of the relationships listed may be represented in a network topology of the network. A routing component 30210 may be configured to detect some or all of the network topology in determining a next protocol address and/or a previous protocol address.
In
In an aspect, determining a next network interface based on a protocol address of a next node may include detecting a network interface identifier in the protocol address. In
As described above, the routing component may determine that a protocol address based on the sequence, “3.0.51”, in the second scope-specific address space, identifies the destination node 30102c7. Further, the hop identifier, ‘3’, may identify, in the second scope-specific address space, the eighth path node 30104c8 as a next node. The number ‘3’, as described above is assigned to identify a hop including the seventh path seventh path node 30104c7 and the eighth path node, and thus identifies a network interface, in the seventh path node 30104c7, that is included in the hop.
Identifying a next network interface may include performing a mapping and/or lookup that maps a portion of a protocol address of a next node to an identifier that identifies a NIC 30213 to a link layer component 30211. A next network interface may be identified by mapping a network layer address to a link layer address by means of a lookup table or record associating the network layer address with the link layer address.
For scope-specific protocol addresses that do not include an identifier of a next node, a similar lookup operation may be performed. In an aspect, a scope-specific address may be mapped to another address space such as global protocol address space or subnet-specific protocol address space shared by nodes in a portion of a network such as a LAN and/or a sub-network. Performing a mapping operation may reduce the number of lookup tables and/or records that must be maintained and/or otherwise accessed.
Protocol addresses illustrated in
In
The one or more network layer protocol data units may be provided to a link layer component 30211 as data to include in one or more link layer protocol data units for transmitting via a NIC 30213 based on the network interface identified by the forwarding component 30206. In a node with one NIC operatively coupled to a physical data transmission medium or with multiple NICs operatively coupled to the shared data transmission medium, an out-data component 30212 may send network layer data units via the one NIC or any of the multiple NICs over the physical data transmission medium for delivery to the destination node according to network interface identified by the forwarding component 30213. Link layer protocol data units may be sent by the link layer component 30211 according to a compatible link layer protocol and link layer address information. For example, Ethernet frames may be sent as link layer protocol data units via an Ethernet cable operatively coupled to a NIC 30213a1 included in a suitable network path for transmitting the data to the destination node.
The following aspects of the method illustrated in
Further, identifying the current-next protocol address may include identifying the current-next protocol address relative to a current location identifier that identifies a current location in a metric space including a network topology representing a node in the current network region. The current-next protocol address identifies a next location in the metric space relative to the current location and the next location represents the next node. The current location may be defined as an origin in the metric space and the current scope-specific address space may be defined based on the metric space and the origin. The current-next protocol address may identify a next network path included in communicatively coupling the current node and the next node and may identify a sequence of locations in the metric space that respectively represent nodes in the next network path according to the network topology.
Additionally, the source-destination protocol address and/or the destination-source protocol address may include a plurality of hop identifiers identifying a sequence of hopes in a network path included in communicatively coupling the source node and the destination node. The address information may include the plurality of hop identifiers in an identifiable first order and in an identifiable second order. The source-destination protocol address may include the plurality of hop identifiers in the first order. The destination-source protocol address may include the plurality of hop identifiers in the second order. One or both of the first order and the second may be identified in the address information. One or both of the first order and the second order may be identified by sequence information represented separately from the plurality of hop identifiers.
A first hop including a first hop node and a second hop node, both in the network path, may be identified with respect to the previous node by a previous hop identifier in a previous scope-specific address space specific to a previous network region that includes the previous node, identified with respect to the current node by a current hop identifier in the current scope-specific address space, and identified with respect to the next node by a next hop identifier in a next scope-specific address space specific to a next network region that includes the next node.
The first hop identifier may be assigned from a first scope-specific address space specific to a first network region that includes a network interface in the first hop node to identify the first hop in response to a negotiation between the nodes in the first hop.
The first hop node and the second hop node are communicatively coupled via a first network interface in the first hop node and via a second network interface in the second hop node, wherein the first hop identifier includes at least one of a first network interface identifier identifying the first network interface and a second network interface identifying the second network interface to at least one of the first hop node and the second hop node.
A current-first path hop identifier that, in the current scope-specific address space, identifies the first hop and the current-first path identifier includes the first hop identifier, wherein the current-first path hop identifier identifies a network path that includes the current node as a path end node, the first hop node, and the second hop node. The first hop may be included in communicatively coupling the current node and one of the source node and the destination node. The current node may be either the first hop node or the second hop node. The previous-current protocol address may include the first hop identifier or the current-next protocol address may include the first hop identifier.
Operating Environment:
An exemplary device included in an operating environment that may be programmed, adapted, modified, and/or otherwise configured according to the subject matter of this disclosure is illustrated in
Processor 303704 may access instructions and data via one or more memory address spaces in addition to the physical memory address space. A memory address space includes addresses identifying locations in a processor memory. The addresses in a memory address space are included in defining a processor memory. Processor 303704 may have more than one processor memory. Thus, processor 303704 may have more than one memory address space. Processor 303704 may access a location in a processor memory by processing an address identifying the location. The processed address may be identified by an operand of an instruction and/or may be identified by a register and/or other portion of processor 303704.
An address space including addresses that identify locations in a virtual processor memory is referred to as a “virtual memory address space”; its addresses are referred to as “virtual memory addresses”; and its processor memory is referred to as a “virtual processor memory” or “virtual memory”. The term “processor memory” may refer to physical processor memory, such as processor memory 303706, and/or may refer to virtual processor memory, such as virtual processor memory 303718, depending on the context in which the term is used.
Physical processor memory 303706 may include various types of memory technologies. Exemplary memory technologies include static random access memory (SRAM), Burst SRAM or SynchBurst SRAM (BSRAM), Dynamic random access memory (DRAM), Fast Page Mode DRAM (FPM DRAM), Enhanced DRAM (EDRAM), Extended Data Output RAM (EDO RAM), Extended Data Output DRAM (EDO DRAM), Burst Extended Data Output DRAM (BEDO DRAM), Enhanced DRAM (EDRAM), synchronous DRAM (SDRAM), JEDEC SRAM, PC 100 SDRAM, Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), SyncLink DRAM (SLDRAM), Ferroelectric RAM (FRAM), RAMBUS DRAM (RDRAM) Direct DRAM (DRDRAM), and/or XDRTM DRAM. Physical processor memory 303706 may include volatile memory as illustrated in the previous sentence and/or may include non-volatile memory such as non-volatile flash RAM (NVRAM) and/or ROM.
Persistent secondary storage 303708 may include one or more flash memory storage devices, one or more hard disk drives, one or more magnetic disk drives, and/or one or more optical disk drives. Persistent secondary storage may include a removable data storage medium. The drives and their associated computer readable media provide volatile and/or nonvolatile storage for computer-executable instructions, data structures, software components, and other data.
Operating environment 303702 may include software components stored in persistent secondary storage 303708, in remote storage accessible via a network, and/or in a processor memory.
Operating environment 303702 may receive user-provided information via one or more input devices illustrated by an input device 303728. Input device 303728 provides input information to other components in operating environment 303702 via input device adapter 303710. Operating environment 303702 may include an input device adapter for a keyboard, a touch screen, a microphone, a joystick, a television receiver, a video camera, a still camera, a document scanner, a fax, a phone, a modem, a network interface adapter, and/or a pointing device, to name a few exemplary input devices.
Input device 303728 included in operating environment 303702 may be included in device 303700 as
An output device 303730 in
A device included in and/or otherwise providing an operating environment may operate in a networked environment communicating with one or more devices via one or more network interface components.
Exemplary devices included in and/or otherwise providing suitable operating environments that may be adapted, programmed, and/or otherwise modified according to the subject matter include a workstation, a desktop computer, a laptop or notebook computer, a server, a handheld computer, a mobile telephone or other portable telecommunication device, a media playing device, a gaming system, a tablet computer, a portable electronic device, a handheld electronic device, a multiprocessor device, a distributed system, a consumer electronic device, a router, a switch, a bridge, a network server, or any other type and/or form of computing, telecommunications, network, and/or media device that is suitable to perform the subject matter described herein. Those skilled in the art will understand that the components illustrated in
Performing the methods described herein, any extensions, and/or any other aspects may include one or more of, but is not limited to, calling a function or method of an object, sending a message via a network; sending a message via an interprocess communication mechanism such as a pipe, a semaphore, a shared data area, and/or a queue; and/or receiving a request such as poll and responding to invoke, and sending an asynchronous message.
To the accomplishment of the foregoing and related ends, the descriptions and annexed drawings set forth certain illustrative aspects and implementations of the disclosure. These are indicative of but a few of the various ways in which one or more aspects of the disclosure may be employed. The other aspects, advantages, and novel features of the disclosure will become apparent from the detailed description included herein when considered in conjunction with the annexed drawings.
Various embodiments set forth herein may be implemented utilizing hardware, software, or any desired combination thereof. For that matter, any type of logic may be utilized which is capable of implementing the various functionality set forth herein.
Illustrative information is provided above regarding various optional architectures and features with which the foregoing frameworks may or may not be implemented, per the desires of the user. It should be strongly noted that such illustrative information is set forth for illustrative purposes and should not be construed as limiting in any manner. Any of the aspects identified by the illustrative information may be optionally incorporated with or without the exclusion of any other of the aspects. Thus, the subject matter described herein may be embodied in many different variations, and all such variations are contemplated to be within the scope of what is claimed.
In the description above, the subject matter is described with reference to acts and symbolic representations of operations that are performed by one or more devices, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processor of data in a structured form. This manipulation transforms the data or maintains it at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the device in a manner well understood by those skilled in the art. The data is maintained at physical locations of the memory as data structures that have particular properties defined by the format of the data. However, while the subject matter is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that various of the acts and operations described hereinafter may also be implemented in hardware.
To facilitate an understanding of the subject matter described above, many aspects are described in terms of sequences of actions that may be performed by elements of a computer system. For example, it will be recognized that the various actions may be performed by specialized circuits or circuitry (e.g., discrete logic gates interconnected to perform a specialized function), by program instructions being executed by one or more processors, or by a combination of both. The description herein of any sequence of actions is not intended to imply that the specific order described for performing that sequence must be followed.
Moreover, the methods described herein may be embodied in executable instructions stored in a computer readable medium for use by or in connection with an instruction execution machine, system, apparatus, or device, such as a computer-based or processor-containing machine, system, apparatus, or device. As used here, a “computer readable medium” may include one or more of any suitable media for storing the executable instructions of a software component in one or more forms including an electronic, magnetic, optical, and electromagnetic form, such that the instruction execution machine, system, apparatus, or device may read (or fetch) the instructions from the non-transitory computer readable medium and execute the instructions for carrying out the described methods. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, software components or other data. Computer storage media includes, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM); Electrically Erasable Programmable Read Only Memory (EEPROM); flash memory or other memory technology; portable computer diskette; Compact Disk Read Only Memory (CDROM), compact disc-rewritable (CDRW), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by an operating environment.
Communication media typically embodies computer readable instructions, data structures, software components, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
Thus, the subject matter described herein may be embodied in many different forms, and all such forms are contemplated to be within the scope of what is claimed. It will be understood that various details may be changed without departing from the scope of the claimed subject matter.
The use of the terms “a” and “a” and “the” and similar referents in the context of describing the subject matter (particularly in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the scope of protection sought is defined by the claims as set forth hereinafter together with any equivalents thereof entitled to. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illustrate the subject matter and does not pose a limitation on the scope of the subject matter unless otherwise claimed. The use of the term “based on” and other like phrases indicating a condition for bringing about a result, both in the claims and in the written description, is not intended to foreclose any other conditions that bring about that result. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention as claimed.
The use of “including”, “comprising”, “having”, and variations thereof are meant to encompass the items listed thereafter and equivalents thereof as well as additional items and equivalents thereof. Terms used to describe interoperation and/or coupling between components are intended to include both direct and indirect interoperation and/or coupling, unless otherwise indicated. Exemplary terms used in describing interoperation and/or coupling include “mounted,” “connected,” “attached,” “coupled,” “communicatively coupled,” “operatively coupled,” “invoked”, “called”, “provided to”, “received from”, “identified to”, “interoperated” and similar terms and their variants.
As used herein, any reference to an entity “in” an association is equivalent to describing the entity as “included in and/or identified by” the association, unless explicitly indicated otherwise.
Unless otherwise defined, unless otherwise defined herein all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. Although methods, components, and devices similar or equivalent to those described herein can be used in the practice or testing of the subject matter described herein, suitable methods, components, and devices are described below.
All publications, patent applications, patents, and other references mentioned herein are incorporated by reference in their entirety, unless explicitly stated otherwise. In case of conflict, the present disclosure, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and not intended to be limiting.
One or more aspects of the disclosure are described with reference to the drawings, wherein like reference numerals are generally utilized to refer to like elements throughout, and wherein the various structures are not necessarily drawn to scale. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more aspects of the disclosure. It may be evident, however, to one skilled in the art, that one or more aspects of the disclosure may be practiced with a lesser degree of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing one or more aspects of the disclosure. It is to be understood that other embodiments and/or aspects may be utilized and structural and functional modifications may be made without departing from the scope of the subject matter disclosed herein.
One or more aspects of the disclosure are described with reference to the drawings, wherein like reference numerals are generally utilized to refer to like elements throughout, and wherein the various structures are not necessarily drawn to scale. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more aspects of the disclosure. It may be evident, however, to one skilled in the art, that one or more aspects of the disclosure may be practiced with a lesser degree of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing one or more aspects of the disclosure. It is to be understood that other embodiments and/or aspects may be utilized and structural and functional modifications may be made without departing from the scope of the subject matter disclosed herein.
An exemplary device included in an execution environment that may be programmed, adapted, modified, and/or otherwise configured according to the subject matter is illustrated in
Processor 40104 may access instructions and data via one or more memory address spaces in addition to the physical memory address space. A memory address space includes addresses identifying locations in a processor memory. The addresses in a memory address space are included in defining a processor memory. Processor 40104 may have more than one processor memory. Thus, processor 40104 may have more than one memory address space. Processor 40104 may access a location in a processor memory by processing an address identifying the location. The processed address may be identified by an operand of an instruction and/or may be identified by a register and/or other portion of processor 40104.
Physical processor memory 40106 may include various types of memory technologies. Exemplary memory technologies include static random access memory (SRAM), Burst SRAM or SynchBurst SRAM (BSRAM), Dynamic random access memory (DRAM), Fast Page Mode DRAM (FPM DRAM), Enhanced DRAM (EDRAM), Extended Data Output RAM (EDO RAM), Extended Data Output DRAM (EDO DRAM), Burst Extended Data Output DRAM (BEDO DRAM), Enhanced DRAM (EDRAM), synchronous DRAM (SDRAM), JEDEC SRAM, PC 40100 SDRAM, Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), SyncLink DRAM (SLDRAM), Ferroelectric RAM (FRAM), RAMBUS DRAM (RDRAM) Direct DRAM (DRDRAM), and/or XDRTM DRAM. Physical processor memory 40106 may include volatile memory as illustrated in the previous sentence and/or may include non-volatile memory such as non-volatile flash RAM (NVRAM) and/or ROM.
Persistent secondary storage 40108 may include one or more flash memory storage devices, one or more hard disk drives, one or more magnetic disk drives, and/or one or more optical disk drives. Persistent secondary storage may include a removable data storage medium. The drives and their associated computer readable media provide volatile and/or nonvolatile storage for computer-executable instructions, data structures, software components, and other data.
Execution environment 40102 may include software components stored in persistent secondary storage 40108, in remote storage accessible via a network, and/or in a processor memory.
Execution environment 40102 may receive user-provided information via one or more input devices illustrated by an input device 40128. Input device 40128 provides input information to other components in execution environment 40102 via input device adapter 40110. Execution environment 40102 may include an input device adapter for a keyboard, a touch screen, a microphone, a joystick, a television receiver, a video camera, a still camera, a document scanner, a fax, a phone, a modem, a network interface adapter, and/or a pointing device, to name a few exemplary input devices.
Input device 40128 included in execution environment 40102 may be included in device 40100 as
An output device 40130 in
A device included in and/or otherwise providing an execution environment may operate in a networked environment communicating with one or more devices via one or more network interface components.
Some components, illustrated in the drawings are identified by numbers with an alphanumeric suffix. A component may be referred to generically in the singular or the plural by dropping a suffix of a portion thereof of the component's identifier. For example, execution environments; such as execution environment 40401a, execution environment 40401b, and their adaptations and analogs; are referred to herein generically as an execution environment 40401 or execution environments 40401 when describing more than one. Other components identified with an alphanumeric suffix may be referred to generically or as a group in a similar manner.
Some or all of the exemplary components illustrated in
A path node 40504 illustrated in any of
The network components in some nodes may be configured according to a layered design or architecture known to those skilled in the art as a “network stack”. Adaptations, analogs, and/or instances of execution environments 40401 in
Some components illustrated in
The network layer component 40403a, illustrated in
In addition to the protocols described above, protocols corresponding to layers in the OSI model above the network layer may be included in communicating via a network. The term “application protocol” as used herein refers to any protocol or combination of protocols that correspond to one or more layers in the OSI reference model above the network layer. Programs and executables operating in execution environments 40401 may communicate via one or more application protocols. Exemplary application protocols include the transmission control protocol (the TCP) in the TCP/IP suite, the user datagram protocol (UDP) in the TCP/IP suite, various versions of hypertext transfer protocol (HTTP), various remote procedure call (RPC) protocols, various instant messaging protocols, various email protocols, and various other protocols for real-time communications. Data exchanged between nodes in a network may be exchanged via data units of one or more network protocols. An execution environment may include layer specific protocol components respectively configured according to the one or more network protocols. Some protocols and/or protocol components may define and/or provide services from multiple layers of the OSI model layer such as the Systems Network Architecture (SNA) protocol.
In addition to specifying schemas defining valid data units, a network protocol may define and/or otherwise be associated with a defined identifier space to identify protocol endpoints defined according to the network protocol. The terms “identifier space” and “address space” are used interchangeably herein. For example, various versions of hypertext transfer protocol (HTTP) specify a format for HTTP uniform resource locators (URL). HTTP specifies a location in an HTTP header that identifies a URL as an identifier or address from the HTTP address space that identifies both a resource and recipient of an HTTP data unit. The transmission control protocol (TCP) specifies a format and vocabulary for a TCP header including a destination protocol endpoint identifier field referred to as a destination port number that, when combined with a destination protocol address from an IP packet, identifies a transport layer protocol endpoint of a receiver of data sent in a TCP data unit via a network. A source protocol endpoint is similarly identified by a source port number, included in a TCP header as defined by the TCP, along with a source protocol address from an IP data unit as defined by the Internet Protocol.
Other exemplary address spaces that identify protocol endpoints in various network protocols include an email address space, a telephone number address space for various telephony protocols, instant message address spaces for various instant message protocols, and media access control (MAC) addresses for various link layer protocols, to name just a few examples. The address spaces identified are shared among the senders and receivers exchanging data via any particular protocol from among those identified herein as well as others that are known. Some address spaces are shared by senders and receivers in a LAN, an intranet, and/or in another identifiable portion of a network. Other address spaces are shared globally. For example, the HTTP identifier space is a global address space shared across the Internet. An HTTP identifier is defined to identify the same resource regardless of the application and/or node identifying the resource via the HTTP identifier. An HTTP URL is a global identifier in an HTTP network, such as the World Wide Web (Web). Addresses in a shared address space are referred to as scoped addresses that serve as identifiers of protocol endpoints in nodes that share the address space in a region of a network defined by a scope.
In delivering data via a network between protocol endpoints of a particular network protocol, addresses from address spaces of the various protocols at the various layers are typically translated and/or otherwise mapped between the various layers. For example, a unicast IP address in an IP packet is mapped to a link layer address for a link via which the IP packet is transported in a network path via a path node 40504 in relaying data from a source node 40502 to an identified destination node 40506. Addresses at the various layers are assigned from a suitable address space for corresponding network protocols.
In
A network topology may represent logical hops in a network. In
Further Details
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
In
For example, the arrangement in
In transmitting data from a source protocol endpoint in a source node 40502 to a destination protocol interface in a destination node 40506, the data is processed by a sequence of nodes in a network path that communicatively couple the source node 40502 and the destination node 40506. A node in the network path that is currently processing the data to send it to the destination 40506, is referred to herein as a “current node” with respect to the data or more precisely referred to as a “current path node” when the current node is a path node. A node in the network path that has previously transmitted the data being processed by the current node is referred to herein as a “previous node”. A node in the network path that has not received the data being processed by the current node is referred to herein as a “next node”. For ease of description, “data” refers to data sent in a data unit via a protocol endpoint in the source node that is being processed by a path node, current to the data, to transmit to a next node in a network path to an identified destination node. As such, a source node 40502 may be a one of a current node and a previous node with respect to particular data. A path node 40504 may be one of a current node, a previous node, and a next node with respect to particular data. A destination node 40506 may be one or a next node and a current node with respect to particular data.
In
A path node 40504 may include an adaptation and/or analog of the execution environment 40401a, illustrated in
An in-data component 40402a may detect one or more network layer protocol data units in data received from the link layer component 40407a. For example, the in-data component 40402a may detect one or more IP packets in data received in one or more Ethernet frames. In-data component 40402a may detect a network layer data unit that includes data from the source node 40502 to relay to the destination node 40506 identified in address information in the detected network layer data unit as defined by a particular network layer protocol.
A network interface component 40405a in a path node 40504 may receive data communicated from a source node 40502 via a previous network path included in a network 40500. One or more network paths may exist for receiving the data. A source node 40502 may be and/or otherwise may include a desktop PC, a notebook, a server, or a handheld computing device serving as a gateway, bridge, or other network relay device.
A path node 40504 may receive data from a source node 40502 to transmit the received data to a destination node 40506 via a specified network protocol. For example, a path node 40504 may receive and transmit a data packet at a link layer as performed by an Ethernet bridge and a multiple protocol labeling switch (MPLS). Further, a path node 40504 may receive and transmit a data packet at a network layer as performed by an Internet protocol (IP) router. Still further, a path node 40504 may receive and transmit a data packet at an application layer, as defined above.
Accordingly, data from a source node 40502 may be included in and/or may include data formatted according a link layer protocol, a network layer protocol, and/or an application layer protocol. An in-data component may operate according to a network layer protocol, a link layer protocol, and/or an application layer protocol.
Data received from a source node 40502 by a path node may be received via one or more previous path nodes 40504 in one or more hops. Data may be received by a current path node 40504 from a previous node based on a previous-current protocol address. The previous-current protocol address may be a path-based addressed and/or may be a scope-specific address that, in a previous scope-specific address space specific to a previous network region that includes the previous node, identifies the current node as described in detail below.
In transmitting data from a source protocol endpoint in a source node 40502 to a destination protocol interface in a destination node 40506, the data is processed by a sequence of nodes in a network path that communicatively couples the source node 40502 and the destination node 40506. A node in the network path that is currently processing the data to send it to the destination 40506, is referred to herein as a “current node” with respect to the data or more precisely referred to as a “current path node” when the current node is a path node. A node in the network path that has previously transmitted the data being processed by the current node is referred to herein as a “previous node”. A node in the network path that has not received the data being processed by the current node is referred to herein as a “next node”. For ease of description, “data” refers to data sent in a one or more data units via a protocol endpoint in the source node where the data is being processed by a path node, current to the data, for transmitting to a next node in a network path to an identified destination node. As such, a source node 40502 may be a one of a current node and a previous node with respect to particular data. A path node 40504 may be one of a current node, a previous node, and a next node with respect to particular data. A destination node 40506 may be one or a next node and a current node with respect to particular data.
In
A routing component 40404a may detect a protocol address of a next node based on a schema for including address information in a data unit of a corresponding network protocol. The address information may be detected in a data unit by the routing component 40404a. In another aspect, address information may be detected by an in-data component 40404a that operates to provide some or all of the address information to the routing component 40404a to detect a protocol address of a next node.
Address representations 40602 in
Alternatively or additionally, a routing component 40404a may identify, based on information in a next address field 40610a, a current protocol address, that, in a next scope-specific address space specific to a next network region that includes the next node, identifies the current node. A routing component 40404a interoperating with an in-data component 40402 may determine a next protocol address, in the current scope-specific address space, that identifies the next node, based on the current protocol address. Further, the next scope-specific address space may be a node-specific address space specific to the next node. In another aspect, a routing component may determine the current address based on the next protocol address.
With respect to
Address information in a data unit may identify a source-destination protocol address that, in a source scope-specific address space specific to a source network region that includes a source node, identifies a destination node and/or may identify a destination-source protocol address, that in a destination scope-specific address space specific to a destination network region that includes the destination node, identifies the source node. A current-next protocol address may be included in at least one of the source-destination protocol address and the destination-source protocol address. The current next address is an address that, in a current scope-specific address space specific to a current network region including a current path node, identifies a next node with respect to the current path node.
At the source node 40502a, the address separator field 40604a may be set, by a separator component 40406a, to include a size of zero for a previous address field 40608a. The address information field 40606a, thus includes a next address field 40610a at the source node 40502a and identifies the destination node 40506a with respect to nodes in the first network region 40510a1.
At a first path node 40504a1, outside the first network region 40510a1, an address separator field 40604a in a data unit including the data from the source node 40502a, may include a value, ‘1’, that identifies, in a previous address field 40608a, a protocol address that, in the first scope-specific address space identifies a second path node 40504a2. A routing component 40404a in a first path node 40504c1 may detect the value. The routing component 40404a interoperating with a separator component 40406a may also identify, based on the value in the address separator field 40604a, a next address field 40610a that identifies “2.2.3.2” as a next protocol address that, in a second scope-specific address space specific to a network interface, of the first path node 40504a1, in a second network region identifies the destination node 40506a. The separator component 40406a may detect the next protocol address. Note that, “2.2.3.2”, identifies the destination node 40506a with respect to all the network interfaces in second network region 40510a2 for transmitting data from a node to the destination interface.
With respect to the destination node 40506a, the second path node 40504a2 is not considered to be in the second network region 40510a2 since the network interface in the second path node 40504a2, that is included in communicatively coupling the second path node 40504a2 to the destination node 40506a, is not included in the second network region 40510a1. The first path node 40504a1, with respect to the destination node 40506a, is included in the second network region 40510a2 since it has a network interface, in the second network region 40510a2, that is included in communicatively coupling the first path node 40504a1 with the destination node 40506a. Similarly, the second path node 40504a2 is included in the second network region 40510a2 with respect to the source node 40502a and the first path node 40504a1 is not included in the second network region 40510a2 with respect to the source node 40502a.
At the destination node 40506a a data unit including the data from the source node 40502a may include a value in an address separator field 40604a that indicates that the address information field includes only a previous address field 40608a identifying “1.2.2.3.2”, which is the destination protocol address when interpreted in the context of the first network region 40510a1.
In another aspect, a routing component 40404 and/or a separator component 40406 may detect, in a data unit by a current node, address separating information specified according to a network protocol to detect the next address information and/or the previous address information. The address separating information may be updated, by the separator component 40406 to identify, by the next node, at least one of next-previous address information and next-next address information in the address information, wherein the next-previous address information includes information identifying the current node. In yet another aspect, address separating information may be updated by a separator component 40406 in a current node to identify, by the current node, the previous address information and the next address information in the address information. As the data from the source node 40502a is transmitted from node to node in the network path the value represented in an address separator field 40604a in an address representation 40602a in a data unit including the data or a portion thereof may be adjusted by various separator components 40406 and/or analogs to identify a protocol address in a suitable address space for the respective nodes in the network path.
At the destination node 40506a, the value in the separator address field and/or in another portion of the data unit may be defined to indicate that the address information field 40606a also includes information for determining and/or otherwise identifying a protocol address that, in a fifth scope-specific address space specific a fifth network region 40510a5 that includes the destination node 40506a, identifies a network interface of a node, in the first network region 40510a1, in a network path from the destination node 40506a to the source node 40502a. The address information field 40606a in some aspects may include information for determining a protocol address that, in the fifth scope-specific address space, identifies the source node 40502a.
The above description describes an address representation 40602a processed in the role of a destination protocol address in a data unit of a network protocol, such as an IP protocol. As a source protocol address with respect to a data unit, described in the previous paragraph, sent from the source node 40502a to the destination node 40506a, an address information field 40606a, at the second path node 40504a2, may include a previous address field 40608a identifying the sequence, “0.0”, that identifies a protocol address that, in the second scope-specific address space, identifies the source node 40502a as a sender of the data in the data unit. Note that the address, “0.0”, identifies the source node 40502a node to all nodes communicating with the source node 40502a via network interfaces in the second network region 40510a2. The address information field 40606a including the source address information at the second path node 40504a2 may include a next address field 40610a, identified by an address separator field 40604a, identifying the sequence “0.1.0” that identifies a protocol address that, in the fifth scope-specific address space, identifies the second path node 40504a2 to the destination node 40506a as a path node 40504a in a network path traversed by the data sent from the source node 40502a.
An in-data component 40402a may detect address information in a data unit specified according to a network protocol to include a destination protocol address portion and a source protocol address portion as, for example, current IP packet headers are specified. Alternatively, an in-data component 40402a may detect address information in a data unit defined to include an address portion that identifies a source protocol address in the context of one scope-specific address space specific to one node in a network path traversed by the packet and identifies a destination node another node in the network path. The Internet Protocol may be adapted to include a schema defining such a data unit as a valid IP packet. Rather than requiring separate source and destination portions, as current IP packet headers require, a single address portion may include address information that identifies a protocol address that is a destination protocol address in one scope-specific address space and a protocol address that is a source protocol address in another. A single address field may also be defined for protocol other than the IP. More details as well as examples are described below.
In an aspect, illustrated in
In
A source node 40502c may identify a destination node 40506c by a destination protocol address, that in a first scope-specific address space specific to a first network region 40510c1 including the first node, identifies the destination node 40506c. The protocol address may be based on a sequence of hop identifiers, “0.1.1.2.3.0.51”. Note that other network paths are illustrated for transmitting data from the source node 40502c to the destination node 40506c and may also identify protocol addresses in the first scope-specific address space that identify the destination node 40506c to nodes in the first network region 40510c1.
A seventh path node 40504c7 in the identified network path may identify the destination node 40506c based on another sequence of hop identifiers, “3.0.51”. The sequence of hop identifiers may identify a protocol address that, in a second scope-specific address space specific to a second network region that includes the seventh path node 40504c7, identifies the destination node 40506c. Note that a routing component 40404a and/or a separator component 40406a operating in the seventh path node 40504c7 may detect the sequence, “3.0.51”, in and/or otherwise based on the protocol address of the destination node 40506c from the first scope-specific address space. Further, the routing component 40402a and/or the separator component 40406a may detect a protocol address for the eighth path node 40504c8 as well as a protocol address for the ninth path node 40504c4, in and/or otherwise based on the sequence, “3.0.51”. The detected protocol addresses may be specific to the second network region 40510c2 as illustrated in
The destination node 40506c is in a third network region 40510c3. Within the third network region 40510c3 the destination node 40506c may be identified by a local-scoped address, ‘51’. Nodes in the third network region 40510c3 may identify nodes outside the third network region 40510c3 with identifiers from a third scope-specific address space specific to the third network region 40510c3 while using local-scoped addresses to identify nodes in the third network region 40510c3.
The hop identifiers, “0.1.1.2.3.0.51”, may be represented in an address representation 40602c in a data unit for sending data from the source node 40502c to the destination node 40506c, in
Note that the address information that identifies one or more protocol addresses for the seventh path node 40504c7 and for the destination node 40506c in the preceding description may include information that identifies a return path or a portion thereof. For example, the sequence address, “3.0.51”, identifies, “0.3”, which may be a protocol address that, in the third scope-specific address space identifies the seventh path node 40504c for the ninth path node 40504c9 operating as a gateway for nodes in the third network region 40510c3. The sequence, “0.1.1.2”, identifies, “2.1.1”, that, in the second-node-specific address space identifies a network path from the seventh path node 40504c7 to a node having a network interface in first network region 40510c1, illustrated by a second path node 40504c2. The second network region 40510c2 may include only one node, thus the second scope-specific address space may be a node-specific address space. A current scope-specific address space for a current node may be a node-specific address space specific to the current node.
The sequence, “0.3”, is not an identifier in the third scope-specific address space as can be seen in
As described in the previous paragraph, a hop may be assigned an identifier that is shared by the pair of nodes in the hop. Thus a sequence of hop identifiers may serve as a scope-specific address in one scope-specific address space when processed in one order of the sequence and may serve as another scope-specific address specific to another node when processed according to another order of the sequence. Any of the address types illustrated in
The protocol address illustrated
In
For a first path node 40504b1, an address representation 40602d in a data unit including data received from the source node 40502b may include previous address information identified by a routing component 40404a based on one or more address separator fields 40604 that identify the “151-254” and/or that identify the sequence “254-151”. The sequence order as “151-254” may identify a protocol address that, in the source node-specific address space, identifies the first path node 40504b1. The sequenced ordered as “254-151” may identify a protocol address that, in a first path node-specific address space specific to the first path node 40504b1, identifies the source node.
Further for the first path node 40504b1, the address representation 40602d may include next address information identified by the routing component 40402a based on one or more address separator fields 40604d that identify the sequence, “151-254.253-105”, in a first order and/or in a second order. The sequence, “151-254.253-105”, in the first order may identify a protocol address that, in the first path node-specific address space, identifies the destination node 40506b. The sequence, “105-253.254-151”, in the second order may identify a protocol address that, in the destination node-specific address space, identifies the first path node 40504b1.
Still further for the first path node 40504b1, the next address information identified by the routing component 40404a identifies the sequence, “151-254”, in a first order and/or in a second order. The sequence, “151-254”, in the first order may identify a protocol address that, in the first path node-specific address space, identifies a second path node 40504c2 in a network path to the destination node 40506b. The sequence, “254-151”, in the second order may identify a protocol address that, in a second path node-specific address space specific to the second path node 40504b2, identifies the first path node 40504b1.
A sequence of hop identifiers based on network interface identifiers may serve as a scope-specific address in one scope-specific address space when processed in one order of the sequence and may serve as another scope-specific address specific to another node when processed according to another order of the sequence.
In
For a second path node 40504b2, an address representation 40602e in a data unit including data received from the source node 40502b may include previous address information identified by a routing component 40404a in the second path node 40504b2 based on one or more address separator fields 40604e that identifies previous sequence, “254.252” in previous address information in the address representation 40602e. The previous sequence may identify a protocol address that, in the first scope-specific address space, identifies the second path node 40504b2.
Further for the second path node 40504b2, the previous address information identified by a routing component 40404a in the second path node 40504b2 identifies a first scoped address, ‘254’, that in the scope of the second network 40514b2 identifies a network interface of the second path node 40504b2 to nodes with network interfaces in the second network 40514b2.
Yet further for the second path node 40504b2, the address representation 40602e may include next address information identified by the routing component 40404a in the second path node 40504b2 based on one or more address separator fields 40604e that identifies a scoped address, ‘105’. The scoped address, ‘105’, in the scope of the third network 40514b3 identifies the destination node 40506b to nodes with network interfaces in the third network 40514b3, such as the second path node 40504c2.
In still another aspect, a scope-specific addresses may conform to a currently-known schema defining a valid Internet Protocol address as specified by RFC 791 and/or RFC 3513 in a scope-specific address space specific to a network region. The scope-specific address is processed as scope-specific as opposed to interpreting it as included in a global address space as is currently done. In one aspect, mapping may be specified between scope-specific address spaces and from the scope-specific address space to a global address space. A mapping may be ruled-based and/or may be specified by associations such as represented by a lookup table.
A routing component 40404a interoperating with a separator component 40406a in a current path node 40504 may detect first address information identifying a current-first protocol address that, in a current scope-specific address space specific to a current network region that includes the current path node 40504, identifies a first node in the network. Second address information identifying a first-second protocol address that, in a first scope-specific address space specific to a first network region that includes the first node, identifies a second node in a network path including the current node for transmitting data from a source node 40502 and an identified destination node 40506. The routing component 40402a operating in the current path node 40504 may detect a relationship between the current-first protocol address and the first-second protocol address. The routing component 40404a may generate a first-to-current mapping rule based on the relationship. The routing component 40404a may process the first-second protocol address based on the first-to-current mapping rule to determine a current-second protocol address that, in the current scope-specific address space, identifies the second node in the network path. The second node may be a next node with respect to the current path node 40504 and the data from the source node 40502. The second node may be the destination node 40506.
In another aspect, a current-first protocol address, “10.22.106.3”, from the current scope-specific address space, may serve as an identifier with respect to the current node of a first node in the network. A second-first protocol address, “40.88.58.1”, in a second scope-specific address space, may serve as an identifier with respect to a second node of the first node. The current-first protocol address and second-first protocol address, in the example, include four parts. The first part of the second-first protocol address is greater by thirty than first part of the current-first protocol address. The second part of the second-first protocol address is greater by sixty-six than the second part of the current-first protocol address. The third part of the second-first protocol address is less by fifty-eight or greater by one hundred ninety-eight, taking the modulus based on a maximum value of two hundred fifty-five, than the third part of the current-first protocol address. The fourth part of the second-first protocol address greater by two or greater by two hundred fifty-four, taking the modulus based on a maximum value of two hundred fifty-five, than the current-first protocol address. A mapping rule may indicate that addresses in the current scope-specific address space have a one-to-one mapping between the current scope-specific address space to the second scope-specific address space that is based on an addend for each of the four portions of the various addresses, additionally taking the modulus of the result based on a maximum value for each address information field. By determining the addend the mapping rule may be determined by a routing component 40402a in the current node. The current-second protocol address from the current scope-specific address space may serve to identify the second node as a next node in the network path. A protocol address in the current scope-specific address that identifies a previous node in the network path may be determined similarly.
A second-second protocol address may be represented as, “200.10.150.33”, that in the second scope-specific address spaces identifies the second node. A routing component 40404 in the current path node 40504 may determine that the current-second protocol address, in the current scope-specific address space, for the second node may be calculated based on the mapping rule represented here as “200+30 mod 256.10+66 mod 256.150+198/mod 256.33+254 mod/256”, or “230.76.92.31”.
The mapping rule may be specific to the current scope-specific address space and the second scope-specific address space, may be specific to an identified group of scope-specific address spaces specific to a respective network regions, and/or may apply among all scope-specific address spaces in use by nodes in the network. Those skilled in the art will see given the examples than many mapping rules exist that allow protocol addresses to be determined from previous address information and next address information according to the method illustrated in
In an aspect, a current scope-specific address space respectively may include identifiers that identify locations, in a multi-dimensional metric space, that is defined based on a plurality of axes that intersect at a current-origin location in the metric space that represents a node in the current scope-specific address space. A network interface of the node at the current-origin location may be identified based on an axis in the plurality of axes. The current-next protocol address may be detected relative to a current-origin address that, in the current scope-specific address space, identifies the current-origin location in the metric space, wherein the current-next protocol address identifies a next location in the metric space relative to the current-origin location and the next location represents the next node.
In related aspect, a current path node 40504, in a network path for transmitting data from a source node 40502 to a destination node 40506, may be in a current network region that has a current scope-specific address space. The current scope-specific address space may include an origin address, such as address “400.400.400.400”, that identifies a network interface of a node in the network identifying an origin node and/or an origin network interface. Protocol addresses in the current scope-specific address space that identify other network interfaces and/or nodes may be defined relative to the origin address based on a specified mapping rule that is defined based on a relationship between the origin node and other network interfaces and/or nodes in the network. The mapping rule may be based on a metric and represented in a network topology of the network.
A mapping rule between a current node-specific address space of a current node and next scope-specific address space specific to a next node may be determined based on an current origin protocol address in the current scope-specific address space a current-next protocol address in the next scope-specific address space that identifies the current node, and a protocol address in the current scope-specific address space of an origin network interface and/or origin node in the next network region.
The mapping rule may specify a coordinate shift and/or a rotation about an axis, for example. The mapping may be pre-specified and accessible to the current node. In another aspect, the current node may determine the mapping based on detected relationships between pairs of protocol addresses respectively from the two scope-specific addresses spaces of the current node and the next node where a protocol address from each of the address spaces that identifies a same node is known to the current node.
Exemplary metric space include Euclidean spaces, non-Euclidean spaces, geo-spaces, and other geometric spaces. A Cartesian coordinate system is an exemplary address space for a Euclidean space. Another example of a geometric address space is a geospatial address space such as used currently in geo-location services. Networks have topologies that may be represented in a geo-space including locations addressed via a geometric address space.
As described various types of protocol addresses may conform to various schemas defining rules for formatting valid protocol addresses and/or defining vocabularies specifying valid content of a protocol address. Given a current node in a network path for transmitting data from a source node to a destination node, the current node may identify a next protocol address and/or a previous protocol address that are scope-specific protocol addresses according to various aspects as described above, and their analogs and extensions.
A next protocol address and/or a previous protocol address may be determined and/or otherwise identified based on one or more of a schema of one or more of a destination protocol address and/or a source protocol address identified in an address information of a data unit, a schema of a scope-specific hop identifier, a mapping between two or more of the schemas or portions thereof of two or more respective scope-specific address spaces, relationships between the nodes to which the protocol addresses are specific, relationships between the scope-specific address spaces of the protocol addresses, and relationships between the nodes in a network that includes them. Some of the relationships listed may be represented in a network topology of the network. A routing component 40404 may detect some or all of the network topology in determining a next protocol address and/or a previous protocol address.
In
Determining a next network interface based on a protocol address of a next node may include detecting a network interface identifier in the protocol address. In
As described above, the routing component may determine that a protocol address based on the sequence, “3.0.51”, in the second scope-specific address space, identifies the destination node 40506c. Further, the hop identifier, ‘3’, may identify, in the second scope-specific address space, the eighth path node 40504c8 as a next node. The number ‘3’, as described above is assigned to identify a hop including the seventh path seventh path node 40504c7 and the eighth path node, and thus identifies a network interface, in the seventh path node 40504c7, that is included in the hop.
Identifying a next network interface may include performing a mapping and/or lookup that maps a portion of a protocol address of a next node to an identifier that identifies a NIC 40405a to a link layer component 40407a. A next network interface may be identified by mapping a network layer address to a link layer address by means of a lookup table or record associating the network layer address with the link layer address.
For scope-specific protocol addresses that do not include an identifier of a next node, a similar lookup operation may be performed. In an aspect, a scope-specific address may be mapped to another address space such as global protocol address space or subnet-specific protocol address space shared by nodes in a portion of a network such as a LAN and/or a sub-network. Performing a mapping operation may reduce the number of lookup tables and/or records that must be maintained and/or otherwise accessed.
Protocol addresses illustrated in
In
The one or more network layer protocol data units may be provided to a link layer component 40407a as data to include in one or more link layer protocol data units for transmitting via a NIC 40405a based on the network interface identified by the forwarding component 40408a. In a node with one NIC operatively coupled to a physical data transmission medium or with multiple NICs operatively coupled to the shared data transmission medium, an out-data component 40410a may send network layer data packets via the one NIC or any of the multiple NICs over the physical data transmission medium for delivery to the destination node 40506 according to network interface identified by the forwarding component 40408a. Link layer protocol data units may be sent by the link layer component 40407a according to a compatible link layer protocol and link layer address information. For example, Ethernet frames may be sent as link layer protocol data units via an Ethernet cable operatively coupled to a NIC 40405a1 included in a suitable network path for transmitting the data to the destination node 40506.
Data, sent from a source node 40502, and an identifier of a destination node 40506 may be received in a data unit of a network protocol by the first NIC 40405b1 in the path node 40504. The data may be detected by an in-data component 40402b1 operatively coupled to first NIC 40405b1. Address information may be detected in an address representation included in the data unit according to the network protocol. The in-data component 40402b1 may send the address information to a routing component 40404b via an internal communications medium 40411b, such as a bus 40116 in
The routing component 40404b interoperating with separator component 40406b may determine the protocol address of the next node as describe above and/or in an analogous manner. The routing component 40404b may provide some or all of the next protocol address to a forwarding component 40408b. The forwarding component 40408 may identify a second line card 40409b2 including a second NIC 40405b2, based on some or all of the next protocol address. The forwarding component 40408b may interoperate with the GPU 40413b to configure the internal data transmission medium 40411b for delivering the data received in the data unit from the first line card 40409b1 to the second line card 40409b2 for final packaging in one or more data units of the network protocol by an out-data component 40410b2. The out-data component 40410b2 operate interoperates with the a second NIC 40405b to transmit the data via a data transmission medium to which the second NIC 40405b2 is operatively coupled.
In
A routing agent (RA) component, such as a first RA component 40404c1, may identify a next protocol address based on address information detected by a first in-data (ID) component 40402c1. Based on some or all of the next protocol address, the first FA component 40408c1 may identifying a next line card 40409c, such as a second line card 40409c2, for transmitting data received from a source node 40502 to a next node identified by the next protocol address as described above with respect to
The following aspects of the method illustrated in
Further, identifying the current-next protocol address may include identifying the current-next protocol address relative to a current location identifier that identifies a current location in a metric space including a network topology representing a node in the current network region. The current-next protocol address identifies a next location in the metric space relative to the current location and the next location represents the next node. The current location may be defined as an origin in the metric space and the current scope-specific address space may be defined based on the metric space and the origin. The current-next protocol address may identify a next network path included in communicatively coupling the current node and the next node and may identify a sequence of locations in the metric space that respectively represent nodes in the next network path according to the network topology.
Additionally, the source-destination protocol address and/or the destination-source protocol address may includes a plurality of hop identifiers identifying a sequence of hopes in a network path included in communicatively coupling the source node and the destination node. The address information may include the plurality of hop identifiers in an identifiable first order and in an identifiable second order. The source-destination protocol address may include the plurality of hop identifiers in the first order. The destination-source protocol address may include the plurality of hop identifiers in the second order. One or both of the first order and the second may be identified in the address information. One or both of the first order and the second order may be identified by sequence information represented separately from the plurality of hop identifiers.
A first hop including a first hop node and a second hop node, both in the network path, may be identified with respect to the previous node by a previous hop identifier in a previous scope-specific address space specific to a previous network region that includes the previous node, identified with respect to the current node by a current hop identifier in the current scope-specific address space, and identified with respect to the next node by a next hop identifier in a next scope-specific address space specific to a next network region that includes the next node.
The first hop identifier may be assigned from a first scope-specific address space specific to a first network region that includes a network interface in the first hop node to identify the first hop in response to a negotiation between the nodes in the first hop.
The first hop node and the second hop node are communicatively coupled via a first network interface in the first hop node and via a second network interface in the second hop node, wherein the first hop identifier includes at least one of a first network interface identifier identifying the first network interface and a second network interface identifying the second network interface to at least one of the first hop node and the second hop node.
A current-first path hop identifier that, in the current scope-specific address space, identifies the first hop and the current-first path identifier includes the first hop identifier, wherein the current-first path hop identifier identifies a network path that includes the current node as a path end node, the first hop node, and the second hop node. The first hop may be included in communicatively coupling the current node and one of the source node and the destination node. The current node may be either the first hop node or the second hop node. The previous-current protocol address may include the first hop identifier or the current-next protocol address may include the first hop identifier.
An execution environment 40401, such as illustrated in
With reference to
For example, the arrangements in
With reference to
For example, the arrangements in
With reference to
For example, the arrangements in
An execution environment 40401, such as illustrated in
With reference to
For example, the arrangements in
With reference to
For example, the arrangements in
With reference to
For example, the arrangements in
An execution environment 40401, such as illustrated in
With reference to
For example, the arrangements in
With reference to
For example, the arrangement in
With reference to
For example, the arrangements in
An execution environment 40401, such as illustrated in
With reference to
For example, the arrangements in
With reference to
For example, the arrangements in
With reference to
For example, the arrangements in
An execution environment 40401, such as illustrated in
With reference to
For example, the arrangements in
With reference to
For example, the arrangements in
With reference to
For example, the arrangements in
With reference to
For example, the arrangement in
To the accomplishment of the foregoing and related ends, the descriptions and annexed drawings set forth certain illustrative aspects and implementations of the disclosure. These are indicative of but a few of the various ways in which one or more aspects of the disclosure may be employed. The other aspects, advantages, and novel features of the disclosure will become apparent from the detailed description included herein when considered in conjunction with the annexed drawings.
It should be understood that the various components illustrated in the various block diagrams represent logical components that operate to perform the functionality described herein and may be implemented in software, hardware, or a combination of the two. While at least one of these components are implemented at least partially as an electronic hardware component, and therefore constitutes a machine, the other components may be implemented in software that when included in an execution environment constitutes a machine, hardware, or a combination of software and hardware.
More particularly, at least one component defined by the claims is implemented at least partially as an electronic hardware component, such as an instruction execution machine (e.g., a processor-based or processor-containing machine) and/or as specialized circuits or circuitry (e.g., discreet logic gates interconnected to perform a specialized function). Other components may be implemented in software, hardware, or a combination of software and hardware. Moreover, some or all of these other components may be combined, some may be omitted altogether, and additional components may be added while still achieving the functionality described herein. Thus, the subject matter described herein may be embodied in many different variations, and all such variations are contemplated to be within the scope of what is claimed.
In the description above, the subject matter is described with reference to acts and symbolic representations of operations that are performed by one or more devices, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processor of data in a structured form. This manipulation transforms the data or maintains it at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the device in a manner well understood by those skilled in the art. The data is maintained at physical locations of the memory as data structures that have particular properties defined by the format of the data. However, while the subject matter is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that various of the acts and operation described hereinafter may also be implemented in hardware.
To facilitate an understanding of the subject matter described above, many aspects are described in terms of sequences of actions that may be performed by elements of a computer system. For example, it will be recognized that the various actions may be performed by specialized circuits or circuitry (e.g., discrete logic gates interconnected to perform a specialized function), by program instructions being executed by one or more processors, or by a combination of both. The description herein of any sequence of actions is not intended to imply that the specific order described for performing that sequence must be followed.
Moreover, the methods described herein may be embodied in executable instructions stored in a computer readable medium for use by or in connection with an instruction execution machine, system, apparatus, or device, such as a computer-based or processor-containing machine, system, apparatus, or device. As used here, a “computer readable medium” may include one or more of any suitable media for storing the executable instructions of a software component in one or more forms including an electronic, magnetic, optical, and electromagnetic form, such that the instruction execution machine, system, apparatus, or device may read (or fetch) the instructions from the non-transitory computer readable medium and execute the instructions for carrying out the described methods. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, software components or other data. Computer storage media includes, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM); Electrically Erasable Programmable Read Only Memory (EEPROM); flash memory or other memory technology; portable computer diskette; Compact Disk Read Only Memory (CDROM), compact disc-rewritable (CDRW), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by an execution environment.
Communication media typically embodies computer readable instructions, data structures, software components, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
Thus, the subject matter described herein may be embodied in many different forms, and all such forms are contemplated to be within the scope of what is claimed. It will be understood that various details may be changed without departing from the scope of the claimed subject matter.
The use of the terms “a” and “a” and “the” and similar referents in the context of describing the subject matter (particularly in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the scope of protection sought is defined by the claims as set forth hereinafter together with any equivalents thereof entitled to. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illustrate the subject matter and does not pose a limitation on the scope of the subject matter unless otherwise claimed. The use of the term “based on” and other like phrases indicating a condition for bringing about a result, both in the claims and in the written description, is not intended to foreclose any other conditions that bring about that result. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention as claimed.
The use of “including”, “comprising”, “having”, and variations thereof are meant to encompass the items listed thereafter and equivalents thereof as well as additional items and equivalents thereof. Terms used to describe interoperation and/or coupling between components are intended to include both direct and indirect interoperation and/or coupling, unless otherwise indicated. Exemplary terms used in describing interoperation and/or coupling include “mounted,” “connected,” “attached,” “coupled,” “communicatively coupled,” “operatively coupled,” “invoked”, “called”, “provided to”, “received from”, “identified to”, “interoperated” and similar terms and their variants.
As used herein, any reference to an entity “in” an association is equivalent to describing the entity as “included in and/or identified by” the association, unless explicitly indicated otherwise.
Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. Although methods, components, and devices similar or equivalent to those described herein can be used in the practice or testing of the subject matter described herein, suitable methods, components, and devices are described below.
All publications, patent applications, patents, and other references mentioned herein are incorporated by reference in their entirety, unless explicitly indicated otherwise. In case of conflict, the present disclosure, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and not intended to be limiting.
One or more aspects of the disclosure are described with reference to the drawings, wherein like reference numerals are generally utilized to refer to like elements throughout, and wherein the various structures are not necessarily drawn to scale. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more aspects of the disclosure. It may be evident, however, to one skilled in the art, that one or more aspects of the disclosure may be practiced with a lesser degree of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing one or more aspects of the disclosure. It is to be understood that other embodiments and/or aspects may be utilized and structural and functional modifications may be made without departing from the scope of the subject matter disclosed herein.
An exemplary device included in an execution environment that may be programmed, adapted, modified, and/or otherwise configured according to the subject matter is illustrated in
Processor 50104 may access instructions and data via one or more memory address spaces in addition to the physical memory address space. A memory address space includes addresses identifying locations in a processor memory. The addresses in a memory address space are included in defining a processor memory. Processor 50104 may have more than one processor memory. Thus, processor 50104 may have more than one memory address space. Processor 50104 may access a location in a processor memory by processing an address identifying the location. The processed address may be identified by an operand of an instruction and/or may be identified by a register and/or other portion of processor 50104.
Physical processor memory 50106 may include various types of memory technologies. Exemplary memory technologies include static random access memory (SRAM), Burst SRAM or SynchBurst SRAM (BSRAM), Dynamic random access memory (DRAM), Fast Page Mode DRAM (FPM DRAM), Enhanced DRAM (EDRAM), Extended Data output RAM (EDO RAM), Extended Data output DRAM (EDO DRAM), Burst Extended Data output DRAM (BEDO DRAM), Enhanced DRAM (EDRAM), synchronous DRAM (SDRAM), JEDEC SRAM, PC 50100 SDRAM, Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), SyncLink DRAM (SLDRAM), Ferroelectric RAM (FRAM), RAMBUS DRAM (RDRAM) Direct DRAM (DRDRAM), and/or XDRTM DRAM. Physical processor memory 50106 may include volatile memory as illustrated in the previous sentence and/or may include non-volatile memory such as non-volatile flash RAM (NVRAM) and/or ROM.
Persistent secondary storage 50108 may include one or more flash memory storage devices, one or more hard disk drives, one or more magnetic disk drives, and/or one or more optical disk drives. Persistent secondary storage may include a removable data storage medium. The drives and their associated computer readable media provide volatile and/or nonvolatile storage for computer-executable instructions, data structures, software components, and other data.
Execution environment 50102 may include software components stored in persistent secondary storage 50108, in remote storage accessible via a network, and/or in a processor memory.
Execution environment 50102 may receive user-provided information via one or more input devices illustrated by an input device 50128. Input device 50128 provides input information to other components in execution environment 50102 via input device adapter 50110. Execution environment 50102 may include an input device adapter for a keyboard, a touch screen, a microphone, a joystick, a television receiver, a video camera, a still camera, a document scanner, a fax, a phone, a modem, a network interface adapter, and/or a pointing device, to name a few exemplary input devices.
Input device 50128 included in execution environment 50102 may be included in device 50100 as
An output device 50130 in
A device included in and/or otherwise providing an execution environment may operate in a networked environment communicating with one or more devices via one or more network interface components.
Some components, illustrated in the drawings are identified by numbers with an alphanumeric suffix. A component may be referred to generically in the singular or the plural by dropping a suffix of a portion thereof of the component's identifier. For example, execution environments; such as execution environment 50401a, execution environment 50401b, and their adaptations and analogs; are referred to herein generically as an execution environment 50401 or execution environments 50401 when describing more than one. Other components identified with an alphanumeric suffix may be referred to generically or as a group in a similar manner.
Some or all of the exemplary components illustrated in
An application, such as an application 50403a and/or an ASD service 50407b, operating in a node 50602, may exchange data with another node 50602 by interoperating with one or more components of a corresponding network stack 50405. In
Transport layer protocols supported by connectionless component 50411a and by connection-oriented component 50413a generate transport layer data units to include data received from an operatively coupled application to deliver the data via the data units according to a network layer protocol to a transport layer protocol endpoint, such as a socket, in another node 50602. Analogously, data sent via an application in another node via a transport layer component may be received according to the network layer protocol by a compatible transport layer component, such as a connection-oriented component 50413a and/or by a connectionless component 50411a, to deliver via a socket to an application operating in the execution environment 50401a in the receiving other node 50602.
A network layer protocol is designed and configured to deliver data across one or more communication links and/or networks between nodes in a network or internet. In
One or more link layer protocols may be included in communicatively coupling a source node and a destination node via a network path that includes one or more path nodes. In
For ease of illustration, the description that follows focuses on IP networks and protocols in the TCP/IP suite due to their wide use and because they are well-known in the art. Those skilled in the art will understand that the scope of the subject matter described is not limited to IP networks.
With respect to
A network layer component 50415a operating in a node 50602 may communicate with one or more nodes 50602 over a LAN, a link, and/or a network of networks such as an intranet or the Internet. A network layer component 50415a in the node 50602 may receive transport layer data units, for example, formatted as TCP packets from a connection-oriented layer component 50413a and/or transport layer data units formatted as UDP packets from a connectionless component 50411a illustrated in
Analogously, the network layer component 50415a interprets data, received from a link layer component 50417a in a node 50602, as IP protocol data and detects IP packets in the received data. The network layer component 50415a may strip off IP layer specific data and transfer the payload of one or more IP packets to the connection-oriented layer component 50413a and/or to the connectionless component 50411a to process as transport layer data units according to a particular transport layer protocol.
As described above,
In addition to the protocols described above, protocols corresponding to layers in the OSI model above the transport layer may be included in communicating via a network. The term “application protocol” as used herein refers to any protocol or combination of protocols that correspond to one or more layers in the OSI reference model above the transport layer. Programs and executables operating in execution environments may communicate via one or more application protocols. Exemplary application protocols include a hypertext transfer protocol (HTTP), various remote procedure call (RPC) protocols, various instant messaging protocol, email protocols, and various presence protocols.
Data exchanged between nodes 50602 in a network 50600 may be exchanged via data units of one or more protocols. Each layer of a network stack may provide a layer specific protocol component. Some protocols, combine services from multiple layers of the OSI model into a single layer such as the Systems Network Architecture (SNA) protocol. Still others may take a hybrid approach. With the advent of software defined networking and flexible protocols such as OpenFlow, new protocols and variations of existing protocols are being introduced and will be introduced that are within the scope of the subject matter of the present disclosure.
A network protocol is defined by one or more formatting rules and/or a vocabulary referred to as a schema. The schema defines valid data units to exchange between and/or among protocol endpoints defined by the respective network protocol. A network protocol also specifies and/or otherwise is compatible with one or more address spaces for identifying protocol endpoints for exchanging data. The terms “identifier space” and “address space” are used interchangeably herein. For example, various versions of hypertext transfer protocol (HTTP) specify a format for HTTP uniform resource locators (URL). HTTP specifies a location in a HTTP header that identifies a URL as an identifier or address from the HTTP address space that identifies both a resource and recipient of a HTTP data unit. The transmission control protocol (TCP) specifies a format and vocabulary for a TCP header including a destination protocol endpoint field for including what the TCP refers to as a destination port number that, when combined with a destination protocol address from an IP packet, identifies a transport layer protocol endpoint of a receiver of data included in a TCP data unit. A sending endpoint is similarly identified by a source port number included in a source protocol endpoint field of a TCP data unit and a source protocol address from an IP data unit.
Other exemplary address spaces that identify protocol endpoints in various protocols include an email address space identifying a protocol endpoint for the simple mail transfer protocol (SMTP), a telephone number address space for various telephony protocols, instant message address spaces for various instant message protocols, and media access control (MAC) addresses for various link layer protocols, to name just a few examples.
In delivering data across a network between protocol endpoints, addresses from address spaces of the various protocols at the various layers may be translated and/or otherwise mapped between the various layers of a network stack. For example, a unicast IP address in an IP packet is mapped to link layer addresses for the various links the IP packet is transported across in a network path via a path node between a source node sending the IP packet and a destination node receiving the IP packet. Addresses at the various layers are assigned from a suitable address space of network protocols of the respective layers.
Since addresses from address spaces at various layers of a network stack are often not suited for remembering and/or identifying by users, an address space of symbolic identifiers or names may be used to provide aliases for addresses in an address space identifying protocol endpoints corresponding to a protocol supported by a layer of a network stack. The domain name space is a well-known identifier space of names for identifying nodes and/or network interfaces as protocol endpoints of the IP protocol in the Internet, private internets, and intranets. The domain name system (DNS) is a collection of domain name system services maintaining databases that associate names from the domain name space with protocol addresses, in particular with IP addresses. The domain name space defines a global name space shared across the Internet.
In
Methods, Systems, and Operation
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
In
For example, the arrangement in
With reference to
For example, the arrangement in
While the subject matter disclosed herein is applicable to network protocols at various layers, the present disclosure describes embodiments at layer three (i.e. the network layer) and layer two (i.e. the link layer) of the OSI stack. Examples of network layer protocols that may be modified to support various types of source routing include an Internet Protocol (IP), DECNet outing Protocol (DRP), an Internetwork Packet Exchange (IPX) protocol, an Internet Datagram Protocol (IDP), a VINES Internet Protocol, and a Datagram Delivery Protocol (DDP). Examples of link layer protocols that may be modified to support source routing as described herein include Ethernet protocols, Token-ring protocols, FDDI protocol, and an asynchronous transfer mode (ATM) protocol.
Data to transmit in a payload portion of a data unit of a network protocol may be received from an application process, such as application 50403a, operating in an execution environment, such as execution environment 50401a in
In an aspect, a source route may be identified by a network protocol address, such as scope-specific protocol address and/or a path-based protocol address. A “source-route protocol address”, as the term is used herein, is a protocol address of a network protocol that identifies a protocol endpoint in a second node for a first node, and that also identifies at least one node that communicatively couples the first node and the second node.
With respect to
A protocol address may be formatted as required by the network protocol and address space supported by the network layer component 50415a. Schemas for source route address spaces are illustrated in
Address information may be detected by the address space component 50402a. The address space component 50402a may interoperate with a packet generator component 50404a, which may include instructions that when executed by processor are included in generating and/or storing a representation of the source-route protocol address as address information in a data unit specified according to the network protocol supported by the network layer component 50415a. The address space component 50402a may interoperate with a packet generator component 50404a to include the address information in the data unit as specified by the network protocol.
In
A packet generator component 50404a in an execution environment 50401a of the first node 50602a1 may include one or more instructions that when performed by the first node 50602a1 identifies a source protocol address based on address information represented in a data unit of a network protocol to identify the first node 50602a1 as the source node of the data in the data unit. The source protocol address may be a source-route protocol address identifying the source node for one or more other nodes in the network. The packet generator component 50404a may interoperate with the address space component 50402a to receive the source address information to include a representation of the source protocol address in the data unit.
An address space component 50402a in the first node 50602a1 may identify a source protocol address that identifies some or all of a route in network 50600a. The sequence, “501.501.500.503”, identifies a route via a sequence of network interfaces in a network path from the second node 50602a2 to the first node 50602a1 that identifies the first node 50602a1. The source protocol address may be pre-specified to the first node 50602a1 via a user and/or may be determined based on a previous communication with the second node 50602a2. The source protocol address may be retrieved via a request to an address space directory service, as described in more detail below.
A packet generator component 50404a may receive source address information that identifies a source-route protocol address that identifies the first node 50602a1. In
Returning to
The packet detector component 431a may detect an address representation in the data unit according to a schema defined by a network layer protocol supported by the network layer component 50415a. The address information represented may be provided to an address space component 50402a. An address space component 50402a operating in the third node 50602a3 may receive and/or otherwise detect the address information via a packet detector component 50431a.
The address space component 50402a may determine an address space that includes a source-route protocol address identified by the address information. For example, the address space component 50402a may identify that a protocol address detected in the address information is in a third scope-specific address space specific to a third region 50606a3 that includes the third node 50602a3 in detecting an identifier of a node, such as the second node 50602a2, that sent the data in the received data unit.
When the protocol address, identified in address information is detected by the address space component 50402a, is not in an address space that is usable for sending data to another node, the address space component 50402a may determine a protocol address in a suitable address space as described in more detail below. The address space component 50402a may receive address information that identifies the third node, in a second scope-specific address space of the second node that sent the data unit. The address space component 50402a may determine a third-second protocol address that, in a third node-specific address space specific to the third node, identifies the second node 50602a2. The data in the data unit may be provided by the network layer component 50415a to a protocol endpoint identified by a higher layer protocol as described above via an out-port component 50433a.
A source-route protocol address may be formatted to be included in data units of an existing network protocol. For example, a schema for a source-route protocol address space may be defined to include an address in the address space in an address field of a header of the IP protocol according to a currently existing specification, such as RFC 791 and/or RFC 3513. While such protocol addresses may have the same or substantially similar rules for valid format and content as those currently in use, the protocol addresses when processed according to the subject matter described herein identify a strict or loose route. For details on the format and vocabularies of current address spaces refer to the appropriate specification. A type bit and/or a pattern of bits in a data unit header may be defined by a network protocol to indicate that address information in the data unit that identifies a protocol address that identifies a source route.
With respect to
At the first node 50602a1, a packet generator component 50404a and/or an address space component 50402a operating in the first node 50602a1 may set and/or otherwise detect a value in the address separator field 50704a that indicates a first address field 50708a has a zero size. The entire address information field 50706a, thus, constitutes a second address field 50710a at the first node 50602a1 and identifies the first-second protocol address that may be set and/or otherwise detected by the separator component 50437.
At a third path node 50604a3, an address separator field 50704a in a data unit including the data from the first node 50602a1 may be set to and/or otherwise may be detected, by a separator component 50435a and/or an address space component 50402a in the third path node 50604a3, as a value that identifies “503.503”, in a first address field 50708a. The information in the first address field 50708a identifies a protocol address identifies the second node 50602a2. The value in the address separator field also identifies a second address field 50710a that identifies “502.502” as a protocol address that, for the first node 50602a1, identifies the third path node 50604a3. At the second node 50602a2 a data unit including the data from the first node 50602a1 may include a value, set and/or detected by a separator component in the second node 50602a2, in an address separator field 50704a that indicates that the address information field 50706a includes only a first address field 50708a identifying “502.502.503.503” as the first protocol address.
As the data from the first node 50602a1 is transmitted from node to node in the network path the value represented in an address separator field 50704a in an address information field 50706a in a data unit including the data or a portion thereof may be adjusted by respective separator components 50528 in respective execution environment 50150 of the nodes in the network path to identify a protocol address in a suitable address space for the respective nodes.
The above describes an address representation 50702a processed to identify destination address information in a data unit of a network protocol, such as an IP protocol and/or a layer two protocol. An address representation 50702a may include source address information with respect to a node receiving data in a data unit, described in the previous paragraph, sent from the first node 50602a1 to the second node 50602a2. An address information field 50706a including source address information at the third path node 50604a3 may include a first address field 50708a identifying the sequence, “500.503”, that identifies a source-route protocol address that, for the third path node 50604a3, identifies the first node 50602a1 as the source node for the data in the data unit. The address information field 50706a including the source address information at the third path node 50604a3 may include a second address field 50710a identifying the sequence “501.501” that identifies a source-route protocol address that, for the second node 50602a2, identifies the third path node 50604a3.
In
A first node 50602c1 may identify a second node 50602c2 by a first-second source-route protocol address that, for a node in a first region 50606c1 including the first node 50602c1, identifies the second node 50602c2. The first-second protocol address may include and/or otherwise may be based on a sequence of hop identifiers “500.501.503.502.501”. Note that other network paths are illustrated for transmitting data from the first node 50602c1 to the second node 50602c2 and may also be and/or otherwise may identify source-route protocol addresses identify the second node 50602c2 to nodes in the first region 50606c1.
The second node 50602c2 may identify a third node 50602c3 by a second-third source-route protocol address that, for the second node 50602c2, identifies the third node 50602c3. The protocol address may be based on a sequence of hop identifiers “501.503.500” that identifies the third node 50602c3 with respect to the second node 50602c2.
The hop identifiers, “500.501.503.502.501”, may be represented in an address representation 50702c in a data unit for sending data from the first node 50602c1 to the second node 50602c2. The hop identifiers, “501.503.501-500”, may be represented in an address representation 50702c in a data unit for sending data from the second node 50602c2 to the third node 50602c3. The identifiers may be given a bit or binary representation and the hop identifiers may be distinguished or separated via address separator fields 50704c as described above with respect to
Note that the address information that identifies source-route protocol addresses for the second node 50602c2 and for the third node 50602c3 in the preceding description may include information for identifying a return path or a portion thereof. For example, the second-third protocol address “501.503.501-500” identifies “500-501.503.501”, which may be included in a third-second protocol address that identifies the second node 50602c2 for nodes to the third node 50602c3. The first-second protocol address, “500.501.503.502.501”, identifies “501.502.503.501” that identifies a network path from the second node to the first region 50606c1. The sequence, “501.502.503.501”, however, does not identify any network interfaces of nodes in the first region 50606c1. Separate source address information may be included in a data unit sent to the second node 50602c2 that includes data sent from the first node 50602c1. The source address information may identify “501.502.503.501.101” as a second-first protocol address that identifies the first node 50602c2. In, the first region 50606c1, ‘101’ may be a scoped address that identifies the first node 50602c1 in the scope of the first region 50606c1. Thus, a source-route protocol address may include a scoped address.
As described in the previous paragraph, a hop may be assigned an identifier that is shared by the pair of nodes in the hop. Thus, a sequence of hop identifiers may serve as a source-route protocol address in one address space when processed in one order of the sequence and may serve as another source-route protocol address specific for another node when processed according to another order of the sequence.
An address separator field 50704d includes series of one valued bits and zero valued bits. A change from a one value to a zero value and vice versa may indicate a boundary that separates protocol endpoint identifiers and/or interface identifiers. An address separator field 50704d1 includes one zero valued bit followed by four one valued bits. The zero valued bit may be defined to indicate that a first network interface in a first hop identifier is one bit long with a corresponding position in the address information field 50706d.
Note that the address separator field 50704d6 does not identify a pair of identifiers and is similar to address separator fields 50704c in
In
Note that reversing the interface identifiers yields the identifier “5010-50151.50254-50151” that may be a protocol address that, for the second node 50602b2, identifies the first node 50602b1. The second node 50602b2 and a third node 50602b3 may be included in regions that respectively include the nodes. Each of the two nodes may identify the other by a protocol address in a respective address space. A sequence of pairs of interface identifiers “5010-50254.50151-5010” may be a protocol address that, for the second node 50602b2, identifies the third node 50602b3. Reversing the interface identifiers yields the identifier “5010-50151.50254-5010” that may be a protocol address that, for the third node 50602b3, identifies the second node 50602b2.
A sequence of hop identifiers based on interface identifiers may serve as a source-route protocol address in one address space when processed in one order of the sequence and may serve as another source-route protocol address for another node when processed according to another order of the sequence.
See application Ser. No. 11/962,285, by the present inventor, filed on 2007 Dec. 21, entitled “Methods and Systems for Sending Information to a Zone Included in an Internet Network” for a description of addresses having outside scope and/or inside scope and processing of such addresses. A third address information field 50706e3 corresponding to a third address separator field 50704e3 may include a pair of identifiers as described with respect to
In
As described above, a source-destination protocol address may include and/or may otherwise identify source-destination path information identifying a source-destination network path included in communicatively coupling the source node and the destination node. A source-destination protocol address may include and/or may otherwise identify first hop information identifying a first hop including a first pair of communicatively coupled nodes included in communicatively coupling the source node and the destination node. At least one the hop identifier may include and/or may otherwise identify an identifier of at least one of the nodes in the first pair. The identifier of the at least one of the nodes in the first pair may include and/or otherwise may identify a network interface that is included in communicatively coupling the first pair. A source-destination protocol address may include and/or may otherwise identify a plurality of hop identifiers in an identifiable first order and in an identifiable second order, wherein the source-destination protocol address includes the plurality of hop identifiers in the first order and a destination-source protocol address, that identifies the source node to the destination node, includes the plurality of hop identifiers in the second order. At least one of the first order and the second order may be identified in the data unit by sequence information defined by a schema of the network protocol. The sequence information may be represented separately from the plurality of hop identifiers
A first hop including a first hop node and a second hop node, both in the network path, may be identified with respect to the source node by a source hop identifier, for example in a source scope-specific address space specific to a source region that includes the source node. The first hop including the first hop node and the second hop node, both in the network path, may be identified with respect to the destination node by a destination hop identifier in the destination scope-specific address space.
The description above with respect to
A protocol address that for a network protocol identifies a second node to a first node may include an identifier of a network path included in communicatively coupling a first node and a second node. For example, with respect to
A protocol address that for a network protocol identifies a second node to a first node may include first hop information identifying a first hop including a first pair of communicatively coupled nodes included in communicatively coupling the first node and the second node. The sequence, “500.501.503.502.503.500-502”, described in the previous paragraph includes the hop identifier “501” which identifies a fifth hop 50608c5 in the network 50600c. The fifth hop 50602c5 includes a fourth path node 50604c4 and a second path node 50604c2, included in a network path that communicatively couples the first node 50602c1 and the eleventh node 50602c11.
A hop identifier in a source-route protocol address may include a network interface identifier of a network interface of a node in the hop. In network 50600b in
A source-route protocol address that for a network protocol identifies a second node to a first node may be defined by a network protocol to include a network interface identifier identifying a network interface included in communicatively coupling a first node and a second node. With respect to
As described above, a source-route protocol address may be identified that, for a destination node, identifies a source node. The protocol address that identifies the destination node may include address information that identifies the source node. In
A network may be represented in a topological space. The domain name system includes a hierarchical representation of the Internet, but currently neither the hierarchical structure of the name space nor the hierarchical structure of the IP address space represents communicatively couplings and/or routes in the network.
As described with respect to
Sending data in a data unit by a first node may include detecting, in the data unit, address separating information specified according to the network protocol for detecting at least one of a first-next protocol address information and a next-first protocol address information. The address separating information may be updated for identifying, by a next node included in communicatively coupling the first node and the second node, the at least one of the first-next protocol address information and next-first protocol address information in the address information, wherein the next-first protocol address information includes information for identifying the first node.
A source-route protocol address, that for a network protocol identifies a second node to a first node, may include a first path node protocol address that, for the first node, identifies a first path node included in a first network path included in communicatively coupling the first node and the second node. Additionally or alternatively, a source-route protocol address, that for a network protocol identifies a second node to a first node, may include a second path node protocol address that, for the path node, identifies the second node. The path node is included in a network path that communicatively couples the first node and the second node Further, identifying a source-route protocol address that for a network protocol identifies a second node to a first node may include identifying, based on the source-route protocol address, the first path node protocol address and based on the second path node protocol address
Sending data from a first node to a second node identified by a source-route protocol address may include sending the data via a path node in a network path communicatively coupling the first node and the second node. The source-route protocol address may include a first path node protocol address that identifies the path node to the first node and the source-route protocol address may include a path node second protocol address that identifies the second node to the first path node for the network protocol
Further, a source-route protocol address that, for a network protocol, identifies a second node to a first node may include a first hop identifier that identifies a first hop in a network path. The first hop may include one or both of the first node and the first path node. A first hop identifier may be assigned to identify the first hop in response to a negotiation between the first node and another node in the first hop. A source-route protocol address that for a network protocol identifies a second node to a first node may include a second hop identifier that identifies a second hop in the network path, wherein the second hop includes at least one of the second node and the first path node
A source-route protocol address that, for a network protocol, identifies a second node to a first node may include a hop identifier that identifies a hop in the network path. The hop includes a first hop node and a second hop node that are communicatively coupled via a first network interface in the first hop node and via a second network interface in the second hop node. The first hop identifier may include at one or more of a first network interface identifier identifying the first network interface and a second network interface identifying the second network interface to at least one of the first hop node and the second hop node
In
A path node 50604 may receive data from a source node 50602 to transmit the received data to a destination node 50602 via a specified network protocol. For example, a path node 50604 may receive and transmit a data unit at a link layer as performed by an Ethernet bridge and a multiple protocol labeling switch (MPLS). Further, a path node 50604 may receive and transmit a data unit at a network layer as performed by an Internet protocol (IP) router. Still further, a path node 50604 may receive and transmit a data unit at an application layer, as defined above.
Data received from a source node by a path node 50604 may be received via one or more previous path nodes 50604 in one or more hops identified in a destination protocol address. Data may be received by a current path node 50604 from a previous node based on a previous-current protocol address. The previous-current protocol address may be a source-route protocol address that, for the previous node, identifies the current node as described in detail below.
In
Whether a protocol address is a source-route protocol address may be determined, by a routing component 50522, by a bit pattern or identifier defined to identify a protocol address type, category, and/or class. The bit pattern or identifier may be located by the routing component 50522 stored in a type bits portion of an IP packet and/or in some other specified location. Those skilled in the art will realize that neither the schemas, which define a format rule(s) and/or a vocabulary rule(s) for a protocol address, described nor the protocols in which their use is described are exhaustive.
An address representation 50702a, in
Alternatively or additionally, a routing component 50522 may identify, based on information in a next address field 50710a, a current protocol address, that identifies the current node. A routing component 50522 interoperating with an in-data component 50520 may determine a next protocol address that identifies the next node, based on the current protocol address. In another aspect, a routing component may determine the current address based on the next protocol address.
With respect to
At a second path node 50604a2, an address separator field 50704a, in a data unit including the data from the first node 50602a1, may include a value, ‘2’, that identifies, in a previous address field 50708a, a protocol address that identifies a second path node 50604a2. A routing component 50522 in a first path node 50604a1 may detect the value. The routing component 50404a interoperating with a separator component 50528 may also identify, based on the value in the address separator field 50704a, a next address field 50710a that identifies “502.503.502” as a next protocol address that identifies the second node 50602a2. The separator component 50528 may detect the next protocol address.
At the second node 50602a2, a data unit including the data from the first node 50602a1 may include a value in an address separator field 50704a that indicates that the address information field includes only a previous address field 50708a identifying “502.502.503.503”, which is the destination protocol address when interpreted in the context of the first network region 50606a1.
In
The above description describes an address representation 50702a processed in the role of a destination protocol address in a data unit of a network protocol, such as an IP protocol. As a source protocol address with respect to a data unit, described in the previous paragraph, sent from the first node 50602a1 to the second node 50602a2, an address information field 50706a, at the second path node 50604a2, may include a previous address field 50708a identifying the sequence, “503”, that identifies a protocol address that identifies the first node 50602a1 as a sender of the data in the data unit. The address information field 50706a including the source address information at the second path node 50604a2 may include a next address field 50710a, identified by an address separator field 50704a, identifying the sequence “501.501.500” that identifies a protocol address that identifies the second path node 50604a2 to the second node 50602a2 as a path node 50604 in a network path traversed by the data sent from the second node 50602a2.
An in-data component 50520 may detect address information in a data unit specified according to a network protocol to include a destination protocol address portion and a source protocol address portion as, for example, current IP packet headers are specified. Alternatively, an in-data component 50520 may detect address information in a data unit defined to include an address portion that identifies a source-route protocol address identifying a source node for one node in a network path traversed by the packet and identifies a source-route protocol address identifying a destination node for another node in the network path.
Address information formatted as illustrated in
In an aspect, illustrated in
In
Note that the address information that identifies one or more protocol addresses for the seventh path node 50604c7 and for the eighth node 50602c8 in the preceding description may include information that identifies a return path or a portion thereof. For example, the sequence address, “503.500.5051”, identifies, “500.503”, which may be a protocol address that identifies the seventh path node 50604c7 for the ninth path node 50604c9 operating as a gateway for nodes in the third network region 50606c3. The sequence, “501.503.502”, identifies, “502.503.501”, that identifies a network path from the seventh path node 50604c7 to a node having a network interface in first network region 50606c1, illustrated by a second path node 50604c2.
A routing component 50522 and/or an in-data component 50520 may operate based on the schema or a portion of the schema illustrated in
For a first path node 50604b1, an address representation 50702d in a data unit including data received from the first node 50602b1 may include previous address information identified by a routing component 50522 based on one or more address separator fields 50704 that identify the “151-254” and/or that identify the sequence “254-151”. The sequence ordered as “151-254” may identify a protocol address that, for the first node 50602b1, identifies the first path node 50604b1. The sequenced ordered as “50254-50151” may identify a protocol address that, for the first path node 50604b1, identifies the first node 50602a1.
Further for the first path node 50604b1, the address representation 50702d may include next address information identified by the routing component 50522 based on one or more address separator fields 50704d that identify the sequence, “50151-50254.50151-50254.50151-5010”, in a first order and/or in a second order. The sequence, “50151-50254.50151-50254.50151-5010”, in the first order may identify a protocol address that, in the first path node-specific address space, identifies the third node 50602b3. The sequence, “5010-50151.50254-50151”, in the second order may identify a protocol address that, in the third node-specific address space, identifies the first path node 50604b1.
In
For a second path node 50604b2, an address representation 50702e in a data unit including data received from the first node 50602b1 may include previous address information identified by a routing component 50522 in the second path node 50604b2 based on one or more address separator fields 50704e that identifies previous sequence, “50254.50254” in previous address information in the address representation 50702e. The previous sequence may identify a protocol address that, for the first node 50602b1, identifies the second path node 50604b2.
Further for the second path node 50604b2, the previous address information identified by a routing component 50522 in the second path node 50604b2 identifies a first scoped address, ‘50254’, that in the scope of the second network 50614b2 identifies a network interface of the second path node 50604b2 to nodes with network interfaces in the second network 50614b2.
Still further for the second path node 50604b2, the address representation 50702e may include next address information identified by the routing component 50522 in the second path node 50604b2 based on one or more address separator fields 50704e that identifies a scoped address, ‘5010’. The scoped address ‘5010’, in the scope of the third network 50614b3, identifies the third node 50602b3 to nodes with network interfaces in the third network 50614b3, such as the second path node 50604c2.
In
Determining a next network interface based on a protocol address of a next node may include detecting a network interface identifier in the protocol address. In
As described above, the routing component may determine that a protocol address based on the sequence, “503.500.51 identifies the eighth node 50602c8 with respect to the seventh path node 50604c7. Further, the hop identifier, ‘3’, may identify the eighth path node 50604c8 as a next node with respect to the seventh path node 50604c7. The number ‘3’, as described above is assigned to identify a hop including the seventh path seventh path node 50604c7 and the eighth path node, and thus identifies a network interface, in the seventh path node 50604c7, that is included in the hop.
A source-route protocol address may include one or more of a first scoped protocol address that identifies a node, in a first pair of nodes in the first-third network path included in communicatively coupling the first node and the third node, to another node in the first pair, wherein the first pair is included in a region of the network included in a span of the first scoped protocol address and a second scoped protocol address that identifies a node, in a second pair of nodes in the third-second network path included in communicatively coupling the second node and the third node, to another node in the second pair, wherein the second pair is included in a region of the network included in a span of the first scoped protocol address. A source-route protocol address may include one or both of a first hop identifier that identifies a first hop that includes a first pair of nodes included in communicatively coupling the first node and the third node and a second hop identifier that identifies a second hop that includes a second pair of nodes included in communicatively coupling the second node and the third node. One or more of the first node, the second node, and the third node are included in the first pair and/or the second pair. A source-route protocol address may include a second hop identifier that identifies the first hop to the first node which is not included in the pair
A source-route protocol address may include first identifiers in a first portion of the plurality that in the first order identifies the first node to a path node and that in the second order identifies the path node to the first node. The source-route protocol address may include second identifiers, in a second portion of the plurality that in the first order identifies the second node to the path node and that in the second order identifies the path node to the second node
A source-route protocol address be identified by an address type field in a data unit header of a network protocol. The address type may identify a loose source route option, a strict source route option, a record route option, routing type zero, or a routing type four.
A source-route protocol address may be included one or more of a scope-specific protocol address, a scoped protocol address, a path-based protocol address, a hop-based protocol address, and a network interface based protocol address.
In an aspect, a first node may instruct a second node to send data to the first node identified by a source-route protocol address. Alternatively or additionally, the first node may instruct the second node to receive and accept data from the first node sent via a source-route protocol address. Still further, the second node may send a request to the first node for a source-route protocol address for communicating with the first node.
With reference to
For example, the arrangement in
A block 50804, in
For example, the arrangement in
With reference to
For example, the arrangement in
A block 50904, in
For example, the arrangement in
In another aspect, for security, performance, energy, pricing, and/or other reasons, a first node may send data to a second node via a first route (loose or strict) and may receive data from the second node via a second route (loose or strict).
With reference to
For example, the arrangement in
A block 501004, in
For example, the arrangement in
A block 501006, in
For example, the arrangement in
As described above, a first node and a second node may utilize more than one route in communicating via a network. To determine an alternate route, one or both of the nodes may request a source-route protocol address from an address space directory service, such as a DNS service.
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
A path node may determine whether to forward a data unit of network protocol based on a number of nodes, hops, and/or network interfaces in a network path traversed by the data and/or in a network path to be traversed by the data. Discarding a data unit that exceeds a hop limit, for example, may discard data units with routes that include a loop. Discarding such data units may, additionally or alternatively, restrict a scope of communications.
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
Alternatively or additionally, source node and/or a path node may detect a loop in a network path identified by a source-route protocol address. A routing component may remove the loop by modifying the source-route protocol address. Alternatively, the data in the data unit may be discarded. Loops may be detected by an ASD service, by matching predefined patterns that may be scope-specific. Pattern matching may be used for detecting relatively small loops in a route, while hop count thresholds may be more efficient for identifying source-route protocol addresses that may include relatively larger loops.
Security, performance, reliability, and the like may be improved by changing a route for sending data to a destination. A path node may change a destination address by identifying a source-route protocol address to change the route to a destination node. For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
A source-route protocol address may include a sequence of scoped addresses. For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
As described above, a route may be changed while data is in transit from a source node to a destination node.
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
To verify that source-route protocol address, a first node and a second node may communicate a source-route protocol address in a data unit of a network protocol addressed with a protocol address that is not a source-route protocol address. Such an exchange may aid in preventing address spoofing.
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
To the accomplishment of the foregoing and related ends, the descriptions and annexed drawings set forth certain illustrative aspects and implementations of the disclosure. These are indicative of but a few of the various ways in which one or more aspects of the disclosure may be employed. The other aspects, advantages, and novel features of the disclosure will become apparent from the detailed description included herein when considered in conjunction with the annexed drawings.
It should be understood that the various components illustrated in the various block diagrams represent logical components that operate to perform the functionality described herein and may be implemented in software, hardware, or a combination of the two. While at least one of these components are implemented at least partially as an electronic hardware component, and therefore constitutes a machine, the other components may be implemented in software that when included in an execution environment constitutes a machine, hardware, or a combination of software and hardware.
More particularly, at least one component defined by the claims is implemented at least partially as an electronic hardware component, such as an instruction execution machine (e.g., a processor-based or processor-containing machine) and/or as specialized circuits or circuitry (e.g., discreet logic gates interconnected to perform a specialized function). Other components may be implemented in software, hardware, or a combination of software and hardware. Moreover, some or all of these other components may be combined, some may be omitted altogether, and additional components may be added while still achieving the functionality described herein. Thus, the subject matter described herein may be embodied in many different variations, and all such variations are contemplated to be within the scope of what is claimed.
In the description above, the subject matter is described with reference to acts and symbolic representations of operations that are performed by one or more devices, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processor of data in a structured form. This manipulation transforms the data or maintains it at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the device in a manner well understood by those skilled in the art. The data is maintained at physical locations of the memory as data structures that have particular properties defined by the format of the data. However, while the subject matter is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that various of the acts and operation described hereinafter may also be implemented in hardware.
To facilitate an understanding of the subject matter described above, many aspects are described in terms of sequences of actions that may be performed by elements of a computer system. For example, it will be recognized that the various actions may be performed by specialized circuits or circuitry (e.g., discrete logic gates interconnected to perform a specialized function), by program instructions being executed by one or more processors, or by a combination of both. The description herein of any sequence of actions is not intended to imply that the specific order described for performing that sequence must be followed.
Moreover, the methods described herein may be embodied in executable instructions stored in a computer readable medium for use by or in connection with an instruction execution machine, system, apparatus, or device, such as a computer-based or processor-containing machine, system, apparatus, or device. As used here, a “computer readable medium” may include one or more of any suitable media for storing the executable instructions of a software component in one or more forms including an electronic, magnetic, optical, and electromagnetic form, such that the instruction execution machine, system, apparatus, or device may read (or fetch) the instructions from the non-transitory computer readable medium and execute the instructions for carrying out the described methods. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage median includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, software components or other data. Computer storage median includes, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM); Electrically Erasable Programmable Read Only Memory (EEPROM); flash memory or other memory technology; portable computer diskette; Compact Disk Read Only Memory (CDROM), compact disc-rewritable (CDRW), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by an execution environment.
Communication media typically embodies computer readable instructions, data structures, software components, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication median includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
Thus, the subject matter described herein may be embodied in many different forms, and all such forms are contemplated to be within the scope of what is claimed. It will be understood that various details may be changed without departing from the scope of the claimed subject matter.
The use of the terms “a” and “a” and “the” and similar referents in the context of describing the subject matter (particularly in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the scope of protection sought is defined by the claims as set forth hereinafter together with any equivalents thereof entitled to. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illustrate the subject matter and does not pose a limitation on the scope of the subject matter unless otherwise claimed. The use of the term “based on” and other like phrases indicating a condition for bringing about a result, both in the claims and in the written description, is not intended to foreclose any other conditions that bring about that result. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention as claimed.
The use of “including”, “comprising”, “having”, and variations thereof are meant to encompass the items listed thereafter and equivalents thereof as well as additional items and equivalents thereof. Terms used to describe interoperation and/or coupling between components are intended to include both direct and indirect interoperation and/or coupling, unless otherwise indicated. Exemplary terms used in describing interoperation and/or coupling include “mounted,” “connected,” “attached,” “coupled,” “communicatively coupled,” “operatively coupled,” “invoked”, “called”, “provided to”, “received from”, “identified to”, “interoperated” and similar terms and their variants.
As used herein, any reference to an entity “in” an association is equivalent to describing the entity as “included in and/or identified by” the association, unless explicitly indicated otherwise.
Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. Although methods, components, and devices similar or equivalent to those described herein can be used in the practice or testing of the subject matter described herein, suitable methods, components, and devices are described below.
All publications, patent applications, patents, and other references mentioned herein are incorporated by reference in their entirety unless otherwise indicated. In case of conflict, the present disclosure, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and not intended to be limiting.
One or more aspects of the disclosure are described with reference to the drawings, wherein like reference numerals are generally utilized to refer to like elements throughout, and wherein the various structures are not necessarily drawn to scale. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more aspects of the disclosure. It may be evident, however, to one skilled in the art, that one or more aspects of the disclosure may be practiced with a lesser degree of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing one or more aspects of the disclosure. It is to be understood that other embodiments and/or aspects may be utilized and structural and functional modifications may be made without departing from the scope of the subject matter disclosed herein.
An exemplary device included in an execution environment that may be programmed, adapted, modified, and/or otherwise configured according to the subject matter is illustrated in
Processor 60104 may access instructions and data via one or more memory address spaces in addition to the physical memory address space. A memory address space includes addresses identifying locations in a processor memory. The addresses in a memory address space are included in defining a processor memory. Processor 60104 may have more than one processor memory. Thus, processor 60104 may have more than one memory address space. Processor 60104 may access a location in a processor memory by processing an address identifying the location. The processed address may be identified by an operand of an instruction and/or may be identified by a register and/or other portion of processor 60104.
Physical processor memory 60106 may include various types of memory technologies. Exemplary memory technologies include static random access memory (SRAM), Burst SRAM or SynchBurst SRAM (BSRAM), Dynamic random access memory (DRAM), Fast Page Mode DRAM (FPM DRAM), Enhanced DRAM (EDRAM), Extended Data output RAM (EDO RAM), Extended Data output DRAM (EDO DRAM), Burst Extended Data output DRAM (BEDO DRAM), Enhanced DRAM (EDRAM), synchronous DRAM (SDRAM), JEDEC SRAM, PC 60100 SDRAM, Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), SyncLink DRAM (SLDRAM), Ferroelectric RAM (FRAM), RAMBUS DRAM (RDRAM) Direct DRAM (DRDRAM), and/or XDRTM DRAM. Physical processor memory 60106 may include volatile memory as illustrated in the previous sentence and/or may include non-volatile memory such as non-volatile flash RAM (NVRAM) and/or ROM.
Persistent secondary storage 60108 may include one or more flash memory storage devices, one or more hard disk drives, one or more magnetic disk drives, and/or one or more optical disk drives. Persistent secondary storage may include a removable data storage medium. The drives and their associated computer readable media provide volatile and/or nonvolatile storage for computer-executable instructions, data structures, software components, and other data.
Execution environment 60102 may include software components stored in persistent secondary storage 60108, in remote storage accessible via a network, and/or in a processor memory.
Execution environment 60102 may receive user-provided information via one or more input devices illustrated by an input device 60128. Input device 60128 provides input information to other components in execution environment 60102 via input device adapter 60110. Execution environment 60102 may include an input device adapter for a keyboard, a touch screen, a microphone, a joystick, a television receiver, a video camera, a still camera, a document scanner, a fax, a phone, a modem, a network interface adapter, and/or a pointing device, to name a few exemplary input devices.
Input device 60128 included in execution environment 60102 may be included in device 60100 as
An output device 60130 in
A device included in and/or otherwise providing an execution environment may operate in a networked environment communicating with one or more devices via one or more network interface components.
Some components, illustrated in the drawings are identified by numbers with an alphanumeric suffix. A component may be referred to generically in the singular or the plural by dropping a suffix of a portion thereof of the component's identifier. For example, execution environments; such as execution environment 60401a, execution environment 60401b, and their adaptations and analogs; are referred to herein generically as an execution environment 60401 or execution environments 60401 when describing more than one. Other components identified with an alphanumeric suffix may be referred to generically or as a group in a similar manner.
Some or all of the exemplary components illustrated in
An application, such as an application 60403a and/or an ASD service 60407b, operating in respective nodes 60602, may exchange data with another node 60602 by interoperating with one or more components of a corresponding network stack 60405. In
Transport layer protocols supported by connectionless component 60411a and by connection-oriented component 60413a generate transport layer data units to include data received from an operatively coupled application to deliver the data via the data units according to a network layer protocol to a transport layer protocol endpoint, such as a socket, in another node 60602. Analogously, data sent via an application in another node via a transport layer component may be received according to the network layer protocol by a compatible transport layer component, such as a connection-oriented component 60413a and/or by a connectionless component 60411a, to deliver via a socket to an application operating in the execution environment 60401a in the receiving other node 60602.
One or more link layer protocols may be included in communicatively coupling a first node and a second node via a network path that includes one or more path nodes. In
With respect to
A network layer component 60415a operating in a node 60602, illustrated in
Analogously, the network layer component 60415a operating in a node 60602 may interpret data, received from a link layer component 60417a, as IP protocol data and may detect IP packets in the received data. The network layer component 60415a may strip off IP layer specific data and transfer the payload of one or more IP packets to the connection-oriented layer component 60413a and/or to the connectionless component 60411a to process as transport layer data units according to a particular transport layer protocol.
In addition to the protocols described above, protocols corresponding to layers in the OSI model above the transport layer may be included in communicating via a network. The term “application protocol” as used herein refers to any protocol or combination of protocols that correspond to one or more layers in the OSI reference model above the transport layer. Programs and executables operating in execution environments may communicate via one or more application protocols. Exemplary application protocols include a hypertext transfer protocol (HTTP), various remote procedure call (RPC) protocols, various instant messaging protocol, email protocols, and various presence protocols.
Data exchanged between nodes 60602 in a network 60600 may be exchanged via data units of one or more protocols. Each layer of a network stack may provide a layer specific protocol component. Some protocols, combine services from multiple layers of the OSI model into a single layer such as the Systems Network Architecture (SNA) protocol. Still others may take a hybrid approach. With the advent of software defined networking and flexible protocols such as OpenFlow, new protocols and variations of existing protocols are being introduced and will be introduced that are within the scope of the subject matter of the present disclosure.
A network protocol specifies and/or is otherwise is compatible with one or more address spaces for identifying protocol endpoints for exchanging data. The terms “identifier space” and “address space” are used interchangeably herein. For example, various versions of hypertext transfer protocol (HTTP) specify a format for HTTP uniform resource locators (URL). HTTP specifies a location in a HTTP header that identifies a URL as an identifier or address from the HTTP address space that identifies both a resource and recipient of a HTTP data unit. The transmission control protocol (TCP) specifies a format and vocabulary for a TCP header including a destination protocol endpoint field for including what the TCP refers to as a destination port number that, when combined with a destination protocol address from an IP packet, identifies a transport layer protocol endpoint of a receiver of data included in a TCP data unit. A sending endpoint is similarly identified by a source port number included in a source protocol endpoint field of a TCP data unit and a source protocol address from an IP data unit.
Other exemplary address spaces that identify protocol endpoints in various protocols include an email address space identifying a protocol endpoint for the simple mail transfer protocol (SMTP), a telephone number address space for various telephony protocols, instant message address spaces for various instant message protocols, and media access control (MAC) addresses for various link layer protocols, to name just a few examples.
Since addresses from address spaces at various layers of a network stack are often not suited for remembering and/or identifying by users, an address space of symbolic identifiers or names may be used to provide aliases for addresses in an address space identifying protocol endpoints corresponding to a protocol supported by a layer of a network stack. The domain name space is a well-known identifier space of names for identifying nodes and/or network interfaces as protocol endpoints of the IP protocol in the Internet, private internets, and intranets. The domain name system (DNS) is a collection of domain name system services maintaining databases that associate names from the domain name space with protocol addresses, in particular with IP addresses. The domain name space defines a global name space shared across the Internet.
In
A path node 60604 may receive data from a source node 60602 to transmit the received data to a destination node 60602 via a specified network protocol. For example, a path node 60604 may receive and transmit a data unit at a link layer as performed by an Ethernet bridge and a multiple protocol labeling switch (MPLS). Further, a path node 60604 may receive and transmit a data unit at a network layer as performed by an Internet protocol (IP) router. Still further, a path node 60604 may receive and transmit a data unit at an application layer, as defined above.
Data received from a source node by a path node 60604 may be received via one or more previous path nodes 60604 in one or more hops identified in a destination protocol address. Data may be received by a current path node 60604 from a previous node based on a previous-current protocol address. The previous-current protocol address may be a source-route protocol address that, for the previous node, identifies the current node as described in detail below.
In
Whether a protocol address is a source-route protocol address may be determined, by a routing component 60522, by a bit pattern or identifier defined to identify a protocol address type, category, and/or class. The bit pattern or identifier may be located by the routing component 60522 stored in a type bits portion of an IP packet and/or in some other specified location. Those skilled in the art will realize that neither the schemas, which define a format rule(s) and/or a vocabulary rule(s) for a protocol address, described nor the protocols in which their use is described are exhaustive.
In
Methods, Systems, and Operation Details
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
In
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
While the subject matter disclosed herein is applicable to network protocols at various layers, the present disclosure describes embodiments at layer three (i.e. the network layer) and layer two (i.e. the link layer) of the OSI stack. Network protocols at other layers of the OSI stack are within the scope of the subject matter described herein. Examples of network layer protocols that may be modified to support various types of source routing include an Internet Protocol (IP), DECNet outing Protocol (DRP), an Internetwork Packet Exchange (IPX) protocol, an Internet Datagram Protocol (IDP), a VINES Internet Protocol, and a Datagram Delivery Protocol (DDP). Examples of link layer protocols that may be modified to support source routing as described herein include Ethernet protocols, Token-ring protocols, FDDI protocol, and an asynchronous transfer mode (ATM) protocol.
Data to transmit in a payload portion of a data unit of a network protocol may be received from an application process, such as application 60403a, operating in an execution environment, such as execution environment 60401a in
With respect to
Schemas for protocol addresses that may be source-route protocol addresses are illustrated in
In
A packet generator component 60408a in an execution environment 60401a of the first node 60602a1 may include one or more instructions that when performed by the first node 60602a1 identifies a protocol address and stores the protocol address in a data unit of the network protocol to identify the first node 60602a1 as the source node of the data in the data unit. The protocol address may be a source-route protocol address identifying the source node for one or more other nodes in the network.
An address space component 60414a in the first node 60602a1 may identify a protocol address that identifies some or all of a route in network 60600a to the first node 60602a1. The sequence, “601.601.600.603”, identifies a route via a sequence of network interfaces in a network path from the second node 60602a2 to the first node 60602a1 that identifies the first node 60602a1. The protocol address may be pre-specified to the first node 60602a1 via a user and/or may be determined based on a previous communication with the second node 60602a2. The protocol address may be retrieved via a request to an address space directory service, as described in more detail below.
In
Returning to
The packet detector component 60431a may detect an address representation in the data unit according to a schema defined by a network layer protocol supported by the network layer component 60415a. The protocol address represented may be provided to an address space component 60414a. An address space component 60414a operating in the third node 60602a3 may receive and/or otherwise detect the protocol address via a packet detector component 60431a.
The address space component 60414a may determine an address space that includes a source-route protocol address identified by the protocol address. For example, the address space component 60414a may identify that a protocol address detected in the protocol address is in a third scope-specific address space specific to a third region 60606a3 that includes the third node 60602a3 in detecting an identifier of a node, such as the second node 60602a2, that sent the data in the received data unit.
When the protocol address is detected by the address space component 60414a, is not in an address space that is usable for sending data to another node, the address space component 60414a may determine a protocol address in a suitable address space as described in more detail below. The address space component 60414a may receive a protocol address that identifies the third node 60602a3, in a second scope-specific address space of the second node 60602a2 that sent the data unit. The address space component 60414a may determine a third-second source-route protocol address that, in a third node-specific address space specific to the third node, identifies the second node 60602a2. The data in the data unit may be provided by the network layer component 60415a to a protocol endpoint identified by a higher layer protocol as described above via an out-port component 60433a.
A source-route protocol address may be formatted to be included in data units of an existing network protocol. For example, a schema for a source-route protocol address space may be defined to include an address in the address space in an address field of a header of the IP protocol according to a currently existing specification, such as RFC 791 and/or RFC 3513. While such protocol addresses may have the same or substantially similar rules for valid format and content as those currently in use, the protocol addresses when processed according to the subject matter described herein identify a strict or loose route. For details on the format and vocabularies of current address spaces refer to the appropriate specification. A type bit and/or a pattern of bits in a data unit header may be defined by a network protocol to indicate that a protocol address in the data unit identifies a source route.
With respect to
At the first node 60602a1, a packet generator component 60408a and/or an address space component 60414a operating in the first node 60602a1 may set and/or otherwise detect a value in the address separator field 60704a that indicates a first address field 60708a has a zero size. The entire protocol address field 60706a, thus, constitutes a second address field 60710a at the first node 60602a1 and identifies the first-second protocol address that may be set and/or otherwise detected by the separator component 60437.
A net-monitor component 60404a may receive a message identifying an attribute of a node, a network interface, a hop, and/or other component of a route. For example, a net-monitor component 60404a in first node 60602a1 may receive information indicating that that a first path node 60604a1 identified by the protocol address “602.602.602.600” is congested, has not provided authorization for relaying data to the second node 60602a2, has a cost associated with it that exceeds a threshold conditions, has been compromised by an attacker, and/or other attribute. In response the net-manager component 60406a may determine whether an alternative route exists from the first node 60602a1 to the second node 60602a1. The net-manager component 60406a may request an alternative route from an ASD service 60403b, in
An attribute for selecting a route may be based on a routing metric. A routing metric may be single dimensional or multi-dimensional. For example, quality of service (QOS) metrics are often multi-dimensional. A routing metric may be analytically specified, empirically specified, or based on one or more analytically specified metrics and one or more empirically specified metrics. A routing metric may be based on one or more of a link, a node, a network interface, one or more network protocols, and a protocol address type. An attribute and/or metric may be based on one or more of latency, throughput, capacity, congestion, an error rate, reliability, security, link utilization, a hop count, a time, a duration, and a data unit size. An attribute or metric may be passively monitored, actively probed, and/or piggy-back probed by one or more nodes in a network which may cooperate in monitoring a network. Nodes that monitor a network may interact as peers, as master-slave, as a hierarchy, and/or any other suitable architecture.
An alternative protocol address and corresponding route may be selected by a path node while data is in transit from the first node 60602a1 to the second node 60602a2. In
As the data from the first node 60602a1 is transmitted from node to node in the network path the value represented in an address separator field 60704a in a protocol address field 60706a in a data unit including the data or a portion thereof may be adjusted by respective separator components 60528 in respective execution environments 60501 of the path nodes in the network path to identify a protocol address in a suitable address space for the respective nodes. As described above, as the data from the first node 60602a1 is transmitted from node to node in the network path the destination protocol address may be changed to select a route to the second node 60602a2 based on attributes of the respective alternative routes, if any.
In an aspect, a protocol address that does not identify a source route may be replaced with a source-route protocol address and vice versa as data traverses a path from a source node to a destination node.
The above describes an address representation 60702a processed to identify a destination protocol address in a data unit of a network protocol, such as an IP protocol and/or a layer two protocol. An address representation 60702a may include a protocol address that identifies a source node to a node receiving data in a data unit. A protocol address field 60706a including a source protocol address at the third path node 60604a3 may include a first address field 60708a identifying the sequence, “600.603”, that identifies a source-route protocol address that, for the third path node 60604a3, identifies the first node 60602a1 as the source node for the data in the data unit. The protocol address field 60706a including the source protocol address at the third path node 60604a3 may include a second address field 60710a identifying the sequence “601.601” that identifies a source-route protocol address that, for the second node 60602a2, identifies the third path node 60604a3.
Just as a destination protocol address may be changed, a source protocol address may also be changed by a source node and/or by one or more path nodes. A source-route protocol address that identifies a source node may identify a same or a different route between the source node and the destination node as a source-route protocol address that identifies one or both of the destination node and the source node. Attribute(s) utilized in selecting a route from the destination node to the source node may differ from the attributes processed in selecting a route from the source node to the destination node. Alternatively or additionally, policies and/or processing of path attributes may differ as well.
In
A first node 60602c1 may identify a second node 60602c2 by a first-second source-route protocol address that, for a node in a first region 60606c1 including the first node 60602c1, identifies the second node 60602c2. The first-second protocol address may include and/or otherwise may be based on a sequence of hop identifiers “600.601.603.602.601”. Note that other network paths are illustrated for transmitting data from the first node 60602c1 to the second node 60602c2 and may also be and/or otherwise may identify source-route protocol addresses identify the second node 60602c2 to nodes in the first region 60606c1.
A node included in transmitting data from a source node to a destination node may select an alternative hop identifier based on an attribute of one of more hops included in communicatively couple the source node and the destination node. For example, the second node 60602a2, in
With respect to
In
See application Ser. No. 11/962,285, by the present inventor, filed on 2007 Dec. 21, entitled “Methods and Systems for Sending Information to a Zone Included in an Internet Network” for a description of addresses having outside scope and/or inside scope and processing of such addresses. A third protocol address field 60706e3 corresponding to a third address separator field 60704e3 may include a pair of identifiers as described with respect to
In
As described above, a source-route protocol address may include and/or may otherwise identify path information identifying a network path included in communicatively coupling a sending node and a receiving node. A source-route protocol address may include and/or may otherwise identify first hop information identifying a first hop including a first pair of communicatively coupled nodes included in communicatively coupling the source node and the destination node. At least one the hop identifier may include and/or may otherwise identify an identifier of at least one of the nodes in the first pair. The identifier of the at least one of the nodes in the first pair may include and/or otherwise may identify a network interface that is included in communicatively coupling the first pair. A source-route protocol address may include and/or may otherwise identify a plurality of hop identifiers in an identifiable first order and in an identifiable second order, wherein the source-route protocol address includes the plurality of hop identifiers in the first order and another source-route protocol address, that identifies the source node to the destination node, includes the plurality of hop identifiers in the second order. At least one of the first order and the second order may be identified in the data unit by sequence information defined by a schema of the network protocol. The sequence information may be represented separately from the plurality of hop identifiers
An address representation 60702a, in
Alternatively or additionally, a routing component 60522 may identify, based on information in a next address field 60710a, a current protocol address, that identifies the current node. A routing component 60522 interoperating with a data-in component 60520 may determine a next protocol address that identifies the next node, based on the current protocol address. In another aspect, a routing component may determine the current address based on the next protocol address.
A source-route protocol address may include one or more of a first scoped protocol address that identifies a node, in a first pair of nodes in the first-third network path included in communicatively coupling the first node and the third node, to another node in the first pair, wherein the first pair is included in a region of the network included in a span of the first scoped protocol address and a second scoped protocol address that identifies a node, in a second pair of nodes in the third-second network path included in communicatively coupling the second node and the third node, to another node in the second pair, wherein the second pair is included in a region of the network included in a span of the first scoped protocol address. A source-route protocol address may include one or both of a first hop identifier that identifies a first hop that includes a first pair of nodes included in communicatively coupling the first node and the third node and a second hop identifier that identifies a second hop that includes a second pair of nodes included in communicatively coupling the second node and the third node. One or more of the first node, the second node, and the third node are included in the first pair and/or the second pair. A source-route protocol address may include a second hop identifier that identifies the first hop to the first node which is not included in the pair
With reference to
With reference to
With reference to
With reference to
With respect to
At a second path node 60604a2, an address separator field 60704a, in a data unit including the data from the first node 60602a1, may include a value, ‘2’, that identifies, in a previous address field 60708a, a protocol address that identifies a third path node 60604a3. A routing component 60522 in a second path node 60604a2 may detect the value. The routing component 60522 interoperating with a separator component 60528 may also identify, based on the value in the address separator field 60704a, a next address field 60710a that identifies “602.602.600” as a next protocol address that identifies the second node 60602a2. The separator component 60528 may detect the next protocol address.
At the second node 60602a2, a data unit including the data from the first node 60602a1 may include a value in an address separator field 60704a that indicates that the protocol address field includes only a previous address field 60708a identifying “602.602.602.600”, which is the destination protocol address in the context of the first network region 60606a1.
In
As a source protocol address with respect to a data unit, described in the previous paragraph, sent from the first node 60602a1 to the second node 60602a2, a protocol address field 60706a, at the second path node 60604a2, may include a previous address field 60708a identifying the sequence, “3”, that identifies a protocol address that identifies the first node 60602a1 as a sender of the data in the data unit. The protocol address field 60706a including the source protocol address at the second path node 60604a2 may include a next address field 60710a, identified by an address separator field 60704a, identifying the sequence “601.601.600” that identifies a protocol address that identifies the second path node 60604a2 to the second node 60602a2 as a path node 60604 in a network path traversed by the data sent from the second node 60602a2.
A data-in component 60520 may detect a protocol address in a data unit specified according to a network protocol to include a destination protocol address portion and a source protocol address portion as, for example, current IP packet headers are specified. Alternatively, a data-in component 60520 may detect a protocol address in a data unit defined to include an address portion that identifies a source-route protocol address identifying a source node for one node in a network path traversed by the packet and identifies a source-route protocol address identifying a destination node for another node in the network path.
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
With reference to
For example, the arrangement in
In an aspect, illustrated in
Hop attribute data may be detected by one or more net-monitor components operating in network 60600c. In
Note that the seventh path node 60604c7 may leave unchanged a source protocol address “602.600.601” that identifies the second node 60602c2 as the source of the data to the sixth node 60602c6. Alternatively, the seventh path node 60604c7 or any other node included in transmitting the data may change the source protocol address to any suitable protocol address that identifies the second node 60602c2 to the sixth node 60602c6. The source protocol address may be a source-route protocol address or not.
With reference to
With reference to
With reference to
In transmitting data from a source node to a destination node, the data may be transmitted by different network protocols corresponding to different portions of a network path from the source node to the destination node. In
Further still, the fourth path node 60604c4 may change network protocols based on a route selected to transmit the data to the second node 60602c2. For example, the fourth path node 60604c4 may select a route from the fourth path node 60604c4 to the second node 60602c2 identified by the protocol address “602.601.600.601”. The fourth path node 60604c4 may send the data in a data unit of the IP protocol, in a payload of an HTTP message, or in some other suitable protocol different than the network protocol associated with the path identified by “603.602.601”.
Different protocols may all map to a same layer of a network stack or may map to different layers. A protocol address may be stored in a data unit of a first network protocol according to a first schema for the first network protocol and the same protocol address may be stored in a data unit of a second network protocol according to a second schema for the second network protocol. An address space component and/or packet generator component may transform the protocol address from a first representation of the first protocol address, valid for the first schema, into a second representation of the protocol address valid for the second schema of the second network protocol.
With reference to
With reference to
With reference to
A routing metric may be selected based on a source node, a destination node, a protocol address of one or more network protocols in a protocol stack, a node in a network path included in communicatively coupling a sending node and a receiving node, a network service provider, a geospatial location, a date, a time, a customer, and the like.
A node may receive a message that identifies a routing metric. A message identifying a routing metric may be received from an ASD service, such as a DNS service and/or service that represents some or all of a network in a topology and/or metric space. Alternatively or additionally, a message identifying a routing metric may be received from a node identified as the destination node for data in a data unit, from a node in a region of the network that includes the destination node, from the source node, from a node in a region of the network that includes the source node, from a path node that may relay data from the source node and the path node. Still further, a routing metric may be identified in a data unit including data from a source node to deliver to a destination node.
In
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
Determining that a network path is not available may include detecting that a node, a hop, a network interface component, and/or software component is not operating to transfer data in a network path. Determining that a network path is not available may include detecting an error condition associated with at least portion of the first network path. Determining that a network path is not available may include determining that no authorization has been granted to send the first data via the first network path. Determining that a network path is not available may include receiving a message including an indicating that the first network path is not available. The message may indicate the network path is not available for sending the first data to the second node. The network path or a portion thereof may be available for other purposes.
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
In an aspect, a source node and/or one or more path nodes included in transmitting data via a network protocol from the source node to a destination node identified by a protocol address of the network protocol, may send the data by more than one route. Some of the data may be sent by one route and some by another. Network efficiency may be improved by sending each packet via a route determined to be optimal for the packet according to a specified criterion. In another aspect, to increase reliability the same data may be sent via more than one route. This ensures data traverses the fastest route in a group of routes and increases the likelihood that the data will reach its destination without resending the data.
In
As described in the previous paragraph, a hop may be assigned an identifier that is shared by the pair of nodes in the hop. Thus, a sequence of hop identifiers may serve as a source-route protocol address in one address space when processed in one order of the sequence and may serve as another source-route protocol address specific for another node when processed according to another order of the sequence.
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
With reference to
An address separator field 60704d includes series of one valued bits and zero valued bits. A change from a one value to a zero value and vice versa may indicate a boundary that separates protocol endpoint identifiers and/or interface identifiers. An address separator field 60704d1 includes one zero valued bit followed by four one valued bits. The zero valued bit may be defined to indicate that a first network interface in a first hop identifier is one bit long with a corresponding position in the protocol address field 60706d.
Note that the address separator field 60704d6 does not identify a pair of identifiers and is similar to address separator fields 60704c in
In an aspect, in changing a protocol address, a received protocol address may be replaced by a protocol address defined by a different schema. For example,
In
Not only are nodes identifiable via source-route protocol addresses, but a hop in a network may be identified by a source-route identifier. Such addresses may be changed in whole or in part by any node included in transferring data between nodes in a network as described above.
A protocol address that for a network protocol identifies a second node to a first node may include an identifier of a network path included in communicatively coupling a first node and a second node. For example, with respect to
A hop identifier in a source-route protocol address may include a network interface identifier of a network interface of a node in the hop. In network 60600b in
A source-route protocol address that for a network protocol identifies a second node to a first node may be defined by a network protocol to include a network interface identifier identifying a network interface included in communicatively coupling a first node and a second node. With respect to
A network may be represented in a topological space. The domain name system includes a hierarchical representation of the Internet, but currently neither the hierarchical structure of the name space nor the hierarchical structure of the IP address space represents communicatively couplings and/or routes in the network.
As described with respect to
A source-route protocol address be identified by an address type field and/or option field in a data unit header of a network protocol. The address type may identify a loose source route option, a strict source route option, a record route option, routing type zero, a routing type four, and the like.
A source-route protocol address may be included one or more of a scope-specific protocol address, a scoped protocol address, a path-based protocol address, a hop-based protocol address, and a network interface-based protocol address.
1. Introduction
1.1. Motivation The Internet Protocol is designed for use in interconnected systems of packet-switched computer communication networks. Such a system has been called a “catenet” [1]. The internet protocol provides for transmitting blocks of data called datagrams from sources to destinations, where sources and destinations are hosts identified by fixed length addresses. The internet protocol also provides for fragmentation and reassembly of long datagrams, if necessary, for transmission through “small packet” networks. 1.2. Scope The internet protocol is specifically limited in scope to provide the functions necessary to deliver a package of bits (an internet datagram) from a source to a destination over an interconnected system of networks. There are no mechanisms to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols. The internet protocol can capitalize on the services of its supporting networks to provide various types and qualities of service. 1.3. Interfaces This protocol is called on by host-to-host protocols in an internet environment. This protocol calls on local network protocols to carry the internet datagram to the next gateway or destination host. For example, a TCP module would call on the internet module to take a TCP segment (including the TCP header and user data) as the data portion of an internet datagram. The TCP module would provide the addresses and other parameters in the internet header to the internet module as arguments of the call. The internet module would then create an internet datagram and call on the local network interface to transmit the internet datagram. In the ARPANET case, for example, the internet module would call on a local net module which would add the 1822 leader [2] to the internet datagram creating an ARPANET message to transmit to the IMP. The ARPANET address would be derived from the internet address by the local network interface and would be the address of some host in the ARPANET, that host might be a gateway to other networks. 1.4. Operation The internet protocol implements two basic functions: addressing and fragmentation. The internet modules use the addresses carried in the internet header to transmit internet datagrams toward their destinations. The selection of a path for transmission is called routing. The internet modules use fields in the internet header to fragment and reassemble internet datagrams when necessary for transmission through “small packet” networks. The model of operation is that an internet module resides in each host engaged in internet communication and in each gateway that interconnects networks. These modules share common rules for interpreting address fields and for fragmenting and assembling internet datagrams. In addition, these modules (especially in gateways) have procedures for making routing decisions and other functions. The internet protocol treats each internet datagram as an independent entity unrelated to any other internet datagram. There are no connections or logical circuits (virtual or otherwise). The internet protocol uses four key mechanisms in providing its service: Type of Service, Time to Live, Options, and Header Checksum. The Type of Service is used to indicate the quality of the service desired. The type of service is an abstract or generalized set of parameters which characterize the service choices provided in the networks that make up the internet. This type of service indication is to be used by gateways to select the actual transmission parameters for a particular network, the network to be used for the next hop, or the next gateway when routing an internet datagram. The Time to Live is an indication of an upper bound on the lifetime of an internet datagram. It is set by the sender of the datagram and reduced at the points along the route where it is processed. If the time to live reaches zero before the internet datagram reaches its destination, the internet datagram is destroyed. The time to live can be thought of as a self destruct time limit. The Options provide for control functions needed or useful in some situations but unnecessary for the most common communications. The options include provisions for timestamps, security, and special routing. The Header Checksum provides a verification that the information used in processing internet datagram has been transmitted correctly. The data may contain errors. If the header checksum fails, the internet datagram is discarded at once by the entity which detects the error. The internet protocol does not provide a reliable communication facility. There are no acknowledgments either end-to-end or hop-by-hop. There is no error control for data, only a header checksum. There are no retransmissions. There is no flow control. Errors detected may be reported via the Internet Control Message Protocol (ICMP) [3] which is implemented in the internet protocol module.
2. Overview
2.1. Relation to Other Protocols The diagram corresponding with
2.3. Function Description The function or purpose of Internet Protocol is to move datagrams through an interconnected set of networks. This is done by passing the datagrams from one internet module to another until the destination is reached. The internet modules reside in hosts and gateways in the internet system. The datagrams are routed from one internet module to another through individual networks based on the interpretation of an internet address. Thus, one important mechanism of the internet protocol is the internet address. In the routing of messages from one internet module to another, datagrams may need to traverse a network whose maximum packet size is smaller than the size of the datagram. To overcome this difficulty, a fragmentation mechanism is provided in the internet protocol. Addressing A distinction is made between names, addresses, and routes [4]. A name indicates what we seek. An address indicates where it is. A route indicates how to get there. The internet protocol deals primarily with addresses. It is the task of higher level (i.e., host-to-host or application) protocols to make the mapping from names to addresses. The internet module maps internet addresses to local net addresses. It is the task of lower level (i.e., local net or gateways) procedures to make the mapping from local net addresses to routes. Addresses are fixed length of four octets (32 bits). An address begins with a network number, followed by local address (called the “rest” field). There are three formats or classes of internet addresses: in class a, the high order bit is zero, the next 7 bits are the network, and the last 24 bits are the local address; in class b, the high order two bits are one-zero, the next 14 bits are the network and the last 16 bits are the local address; in class c, the high order three bits are one-one-zero, the next 21 bits are the network and the last 8 bits are the local address. Care must be taken in mapping internet addresses to local net addresses; a single physical host must be able to act as if it were several distinct hosts to the extent of using several distinct internet addresses. Some hosts will also have several physical interfaces (multi-homing). That is, provision must be made for a host to have several physical interfaces to the network with each having several logical internet addresses. Examples of address mappings may be found in “Address Mappings” [5]. Fragmentation Fragmentation of an internet datagram is necessary when it originates in a local net that allows a large packet size and must traverse a local net that limits packets to a smaller size to reach its destination. An internet datagram can be marked “don't fragment.” Any internet datagram so marked is not to be internet fragmented under any circumstances. If internet datagram marked don't fragment cannot be delivered to its destination without fragmenting it, it is to be discarded instead. Fragmentation, transmission and reassembly across a local network which is invisible to the internet protocol module is called intranet fragmentation and may be used [6]. The internet fragmentation and reassembly procedure needs to be able to break a datagram into an almost arbitrary number of pieces that can be later reassembled. The receiver of the fragments uses the identification field to ensure that fragments of different datagrams are not mixed. The fragment offset field tells the receiver the position of a fragment in the original datagram. The fragment offset and length determine the portion of the original datagram covered by this fragment. The more-fragments flag indicates (by being reset) the last fragment. These fields provide sufficient information to reassemble datagrams. The identification field is used to distinguish the fragments of one datagram from those of another. The originating protocol module of an internet datagram sets the identification field to a value that must be unique for that source-destination pair and protocol for the time the datagram will be active in the internet system. The originating protocol module of a complete datagram sets the more-fragments flag to zero and the fragment offset to zero. To fragment a long internet datagram, an internet protocol module (for example, in a gateway), creates two new internet datagrams and copies the contents of the internet header fields from the long datagram into both new internet headers. The data of the long datagram is divided into two portions on a 8 octet (64 bit) boundary (the second portion might not be an integral multiple of 8 octets, but the first must be). Call the number of 8 octet blocks in the first portion NFB (for Number of Fragment Blocks). The first portion of the data is placed in the first new internet datagram, and the total length field is set to the length of the first datagram. The more-fragments flag is set to one. The second portion of the data is placed in the second new internet datagram, and the total length field is set to the length of the second datagram. The more-fragments flag carries the same value as the long datagram. The fragment offset field of the second new internet datagram is set to the value of that field in the long datagram plus NFB. This procedure can be generalized for an n-way split, rather than the two-way split described. To assemble the fragments of an internet datagram, an internet protocol module (for example at a destination host) combines internet datagrams that all have the same value for the four fields: identification, source, destination, and protocol. The combination is done by placing the data portion of each fragment in the relative position indicated by the fragment offset in that fragment's internet header. The first fragment will have the fragment offset zero, and the last fragment will have the more-fragments flag reset to zero. 2.4. Gateways Gateways implement internet protocol to forward datagrams between networks. Gateways also implement the Gateway to Gateway Protocol (GGP) [7] to coordinate routing and other internet control information. In a gateway the higher level protocols need not be implemented and the GGP functions are added to the IP module. Such configuration is also found in
3. Specification
3.1. Internet Header Format A summary of the contents of the internet header is found in
The following internet options are defined, as shown in
Examples & Scenarios Example 1: This is an example of the minimal data carrying internet datagram and is found in
GLOSSARY 1822 BBN Report 1822, “The Specification of the Interconnection of a Host and an IMP”. The specification of interface between a host and the ARPANET. ARPANET leader The control information on an ARPANET message at the host-IMP interface. ARPANET message The unit of transmission between a host and an IMP in the ARPANET. The maximum size is about 1012 octets (8096 bits). ARPANET packet A unit of transmission used internally in the ARPANET between IMPs. The maximum size is about 126 octets (1008 bits). Destination The destination address, an internet header field. DF The Don't Fragment bit carried in the flags field. Flags An internet header field carrying various control flags. Fragment Offset This internet header field indicates where in the internet datagram a fragment belongs. GGP Gateway to Gateway Protocol, the protocol used primarily between gateways to control routing and other gateway functions. header Control information at the beginning of a message, segment, datagram, packet or block of data. ICMP Internet Control Message Protocol, implemented in the internet module, the ICMP is used from gateways to hosts and between hosts to report errors and make routing suggestions. Identification An internet header field carrying the identifying value assigned by the sender to aid in assembling the fragments of a datagram. IHL The internet header field Internet Header Length is the length of the internet header measured in 32 bit words. IMP The Interface Message Processor, the packet switch of the ARPANET. Internet Address A four octet (32 bit) source or destination address consisting of a Network field and a Local Address field. internet datagram The unit of data exchanged between a pair of internet modules (includes the internet header). internet fragment A portion of the data of an internet datagram with an internet header. Local Address The address of a host within a network. The actual mapping of an internet local address on to the host addresses in a network is quite general, allowing for many to one mappings. MF The More-Fragments Flag carried in the internet header flags field. module An implementation, usually in software, of a protocol or other procedure. more-fragments flag A flag indicating whether or not this internet datagram contains the end of an internet datagram, carried in the internet header Flags field. NFB The Number of Fragment Blocks in a the data portion of an internet fragment. That is, the length of a portion of data measured in 8 octet units. octet An eight bit byte. Options The internet header Options field may contain several options, and each option may be several octets in length. Padding The internet header Padding field is used to ensure that the data begins on 32 bit word boundary. The padding is zero. Protocol In this document, the next higher level protocol identifier, an internet header field. Rest The local address portion of an Internet Address. Source The source address, an internet header field. TCP Transmission Control Protocol: A host-to-host protocol for reliable communication in internet environments. TCP Segment The unit of data exchanged between TCP modules (including the TCP header). TFTP Trivial File Transfer Protocol: A simple file transfer protocol built on UDP. Time to Live An internet header field which indicates the upper bound on how long this internet datagram may exist. TOS Type of Service Total Length The internet header field Total Length is the length of the datagram in octets including internet header and data. TTL Time to Live Type of Service An internet header field which indicates the type (or quality) of service for this internet datagram. UDP User Datagram Protocol: A user level protocol for transaction oriented applications. User The user of the internet protocol. This may be a higher level protocol module, an application program, or a gateway program. Version The Version field indicates the format of the internet header.
1.0 Introduction This document defines an IPv6 aggregatable global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [IPV6] and the “IPv6 Addressing Architecture” [ARCH]. It is designed to facilitate scalable Internet routing. This documented replaces RFC 2073, “An IPv6 Provider-Based Unicast Address Format”. RFC 2073 will become historic. The Aggregatable Global Unicast Address Format is an improvement over RFC 2073 in a number of areas. The major changes include removal of the registry bits because they are not needed for route aggregation, support of EUI-64 based interface identifiers, support of provider and exchange based aggregation, separation of public and site topology, and new aggregation based terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119].
2.0 Overview of the IPv6 Address IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces. There are three types of addresses: Unicast, Anycast, and Multicast. This document defines a specific type of Unicast address. In this document, fields in addresses are given specific names, for example “subnet”. When this name is used with the term “ID” (for “identifier”) after the name (e.g., “subnet ID”), it refers to the contents of the named field. When it is used with the term “prefix” (e.g. “subnet prefix”) it refers to all of the addressing bits to the left of and including this field. IPv6 unicast addresses are designed assuming that the Internet routing system makes forwarding decisions based on a “longest prefix match” algorithm on arbitrary bit boundaries and does not have any knowledge of the internal structure of IPv6 addresses. The structure in IPv6 addresses is for assignment and allocation. The only exception to this is the distinction made between unicast and multicast addresses. The specific type of an IPv6 address is indicated by the leading bits in the address. The variable-length field comprising these leading bits is called the Format Prefix (FP). This document defines an address format for the 001 (binary) Format Prefix for Aggregatable Global Unicast addresses. The same address format could be used for other Format Prefixes, as long as these Format Prefixes also identify IPv6 unicast addresses. Only the “001” Format Prefix is defined here.
3.0 IPv6 Aggregatable Global Unicast Address Format This document defines an address format for the IPv6 aggregatable global unicast address assignment. The authors believe that this address format will be widely used for IPv6 nodes connected to the Internet. This address format is designed to support both the current provider-based aggregation and a new type of exchange-based aggregation. The combination will allow efficient routing aggregation for sites that connect directly to providers and for sites that connect to exchanges. Sites will have the choice to connect to either type of aggregation entity. While this address format is designed to support exchange-based aggregation (in addition to current provider-based aggregation) it is not dependent on exchanges for it's overall route aggregation properties. It will provide efficient route aggregation with only provider-based aggregation. Aggregatable addresses are organized into a three level hierarchy: —Public Topology—Site Topology—Interface Identifier Public topology is the collection of providers and exchanges who provide public Internet transit services. Site topology is local to a specific site or organization which does not provide public transit service to nodes outside of the site. Interface identifiers identify interfaces on links. As shown in the foregoing, as well as in
3.1 Aggregatable Global Unicast Address Structure The aggregatable global unicast address format is shown in
3.2 Top-Level Aggregation ID Top-Level Aggregation Identifiers (TLA ID) are the top level in the routing hierarchy. Default-free routers must have a routing table entry for every active TLA ID and will probably have additional entries providing routing information for the TLA ID in which they are located. They may have additional entries in order to optimize routing for their specific topology, but the routing topology at all levels must be designed to minimize the number of additional entries fed into the default free routing tables. This addressing format supports 8,192 (2{circumflex over ( )}13) TLA ID's. Additional TLA ID's may be added by either growing the TLA field to the right into the reserved field or by using this format for additional format prefixes. The issues relating to TLA ID assignment are beyond the scope of this document. They will be described in a document under preparation.
3.3 Reserved The Reserved field is reserved for future use and must be set to zero. The Reserved field allows for future growth of the TLA and NLA fields as appropriate. See section 4.0 for a discussion.
3.4 Next-Level Aggregation Identifier Next-Level Aggregation Identifier's are used by organizations assigned a TLA ID to create an addressing hierarchy and to identify sites. The organization can assign the top part of the NLA ID in a manner to create an addressing hierarchy appropriate to its network. It can use the remainder of the bits in the field to identify sites it wishes to serve. This is shown in
4.0 Technical Motivation The design choices for the size of the fields in the aggregatable address format were based on the need to meet a number of technical requirements. These are described in the following paragraphs. The size of the Top-Level Aggregation Identifier is 13 bits. This allows for 8,192 TLA ID's. This size was chosen to insure that the default-free routing table in top level routers in the Internet is kept within the limits, with a reasonable margin, of the current routing technology. The margin is important because default-free routers will also carry a significant number of longer (i.e., more-specific) prefixes for optimizing paths internal to a TLA and between TLAs. The important issue is not only the size of the default-free routing table, but the complexity of the topology that determines the number of copies of the default-free routes that a router must examine while computing a forwarding table. Current practice with IPv4 it is common to see a prefix announced fifteen times via different paths. The complexity of Internet topology is very likely to increase in the future. It is important that IPv6 default-free routing support additional complexity as well as a considerably larger internet. It should be noted for comparison that at the time of this writing (spring, 1998) the IPv4 default-free routing table contains approximately 50,000 prefixes. While this shows that it is possible to support more routes than 8,192 it is matter of debate if the number of prefixes supported today in IPv4 is already too high for current routing technology. There are serious issues of route stability as well as cases of providers not supporting all top level prefixes. The technical requirement was to pick a TLA ID size that was below, with a reasonable margin, what was being done with IPv4. The choice of 13 bits for the TLA field was an engineering compromise. Fewer bits would have been too small by not supporting enough top level organizations. More bits would have exceeded what can be reasonably accommodated, with a reasonable margin, with current routing technology in order to deal with the issues described in the previous paragraphs. If in the future, routing technology improves to support a larger number of top level routes in the default-free routing tables there are two choices on how to increase the number TLA identifiers. The first is to expand the TLA ID field into the reserved field. This would increase the number of TLA ID's to approximately 2 million. The second approach is to allocate another format prefix (FP) for use with this address format. Either or a combination of these approaches allows the number of TLA ID's to increase significantly. The size of the Reserved field is 8 bits. This size was chosen to allow significant growth of either the TLA ID and/or the NLA ID fields. The size of the Next-Level Aggregation Identifier field is 24 bits. This allows for approximately sixteen million NLA ID's if used in a flat manner. Used hierarchically it allows for a complexity roughly equivalent to the IPv4 address space (assuming an average network size of 254 interfaces). If in the future additional room for complexity is needed in the NLA ID, this may be accommodated by extending the NLA ID into the Reserved field. The size of the Site-Level Aggregation Identifier field is 16 bits. This supports 65,535 individual subnets per site. The design goal for the size of this field was to be sufficient for all but the largest of organizations. Organizations which need additional subnets can arrange with the organization they are obtaining Internet service from to obtain additional site identifiers and use this to create additional subnets. The Site-Level Aggregation Identifier field was given a fixed size in order to force the length of all prefixes identifying a particular site to be the same length (i.e., 48 bits). This facilitates movement of sites in the topology (e.g., changing service providers and multi-homing to multiple service providers). The Interface ID Interface Identifier field is 64 bits. This size was chosen to meet the requirement specified in [ARCH] to support EUI-64 based Interface Identifiers.
5.0 Acknowledgments The authors would like to express our thanks to Thomas Narten, Bob Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema, Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg for their review and constructive comments.
6.0 References [ALLOC] IAB and IESG, “IPv6 Address Allocation Management”, RFC 1881, December 1995. [ARCH] Hinden, R., “IP Version 6 Addressing Architecture”, RFC 2373, July 1998. [AUTH] Atkinson, R., “IP Authentication Header”, RFC 1826, August 1995. [AUTO] Thompson, S., and T. Narten., “IPv6 Stateless Address Autoconfiguration”, RFC 1971, August 1996. [ETHER] Crawford, M., “Transmission of IPv6 Packets over Ethernet Networks”, Work in Progress. [EUI64] IEEE, “Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority”, http://standards.ieee.org/db/oui/tutorials/EUI64.html, March 1997. [FDDI] Crawford, M., “Transmission of IPv6 Packets over FDDI Networks”, Work in Progress. [IPV6] Deering, S., and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 1883, December 1995. [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and J. Postel, “Internet Registry IP Allocation Guidelines”, BCP 12, RFC 1466, November 1996. [RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
7.0 Security Considerations IPv6 addressing documents do not have any direct impact on Internet infrastructure security. Authentication of IPv6 packets is defined in [AUTH].
1. Introduction IP version 6 (IPv6) is a new version of the Internet Protocol, designed as the successor to IP version 4 (IPv4) [RFC-791]. The changes from IPv4 to IPv6 fall primarily into the following categories: o Expanded Addressing Capabilities IPv6 increases the IP address size from 32 bits to 128 bits, to support more levels of addressing hierarchy, a much greater number of addressable nodes, and simpler auto-configuration of addresses. The scalability of multicast routing is improved by adding a “scope” field to multicast addresses. And a new type of address called an “anycast address” is defined, used to send a packet to any one of a group of nodes. o Header Format Simplification Some IPv4 header fields have been dropped or made optional, to reduce the common-case processing cost of packet handling and to limit the bandwidth cost of the IPv6 header. o Improved Support for Extensions and Options Changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future. o Flow Labeling Capability A new capability is added to enable the labeling of packets belonging to particular traffic “flows” for which the sender requests special handling, such as non-default quality of service or “real-time” service. o Authentication and Privacy Capabilities Extensions to support authentication, data integrity, and (optional) data confidentiality are specified for IPv6. This document specifies the basic IPv6 header and the initially-defined IPv6 extension headers and options. It also discusses packet size issues, the semantics of flow labels and traffic classes, and the effects of IPv6 on upper-layer protocols. The format and semantics of IPv6 addresses are specified separately in [ADDRARCH]. The IPv6 version of ICMP, which all IPv6 implementations are required to include, is specified in [ICMPv6].
2. Terminology node—a device that implements IPv6. router—a node that forwards IPv6 packets not explicitly addressed to itself. [See Note below]. host—any node that is not a router. [See Note below]. upper layer—a protocol layer immediately above IPv6. Examples are transport protocols such as TCP and UDP, control protocols such as ICMP, routing protocols such as OSPF, and internet or lower-layer protocols being “tunneled” over (i.e., encapsulated in) IPv6 such as IPX, AppleTalk, or IPv6 itself. link—a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and internet (or higher) layer “tunnels”, such as tunnels over IPv4 or IPv6 itself. neighbors—nodes attached to the same link. interface—a node's attachment to a link. address—an IPv6-layer identifier for an interface or a set of interfaces. packet—an IPv6 header plus payload. link MTU—the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed over a link. path MTU—the minimum link MTU of all the links in a path between a source node and a destination node. Note: it is possible, though unusual, for a device with multiple interfaces to be configured to forward non-self-destined packets arriving from some set (fewer than all) of its interfaces, and to discard non-self-destined packets arriving from its other interfaces. Such a device must obey the protocol requirements for routers when receiving packets from, and interacting with neighbors over, the former (forwarding) interfaces. It must obey the protocol requirements for hosts when receiving packets from, and interacting with neighbors over, the latter (non-forwarding) interfaces.
3. IPv6 Header Format is shown in
4. IPv6 Extension Headers In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper-layer header in a packet. There are a small number of such extension headers, each identified by a distinct Next Header value. As illustrated in
4.2 Options Two of the currently-defined extension headers—the Hop-by-Hop Options header and the Destination Options header—carry a variable number of type-length-value (TLV) encoded “options”, illustrated in
4.4 Routing Header The Routing header is used by an IPv6 source to list one or more intermediate nodes to be “visited” on the way to a packet's destination. This function is very similar to IPv4's Loose Source and Record Route option. The Routing header is identified by a Next Header value of 43 in the immediately preceding header, and has the format shown in
The Type 0 Routing header has the format shown in
4.5 Fragment Header The Fragment header is used by an IPv6 source to send a packet larger than would fit in the path MTU to its destination. (Note: unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path—see section 5.) The Fragment header is identified by a Next Header value of 44 in the immediately preceding header, and has the format shown in
The initial, large, unfragmented packet is referred to as the “original packet”, and it is considered to consist of two parts, as illustrated in
Each fragment packet is composed of: (1) The Unfragmentable Part of the original packet, with the Payload Length of the original IPv6 header changed to contain the length of this fragment packet only (excluding the length of the IPv6 header itself), and the Next Header field of the last header of the Unfragmentable Part changed to 44. (2) A Fragment header containing: The Next Header value that identifies the first header of the Fragmentable Part of the original packet. A Fragment Offset containing the offset of the fragment, in 8-octet units, relative to the start of the Fragmentable Part of the original packet. The Fragment Offset of the first (“leftmost”) fragment is 0. An M flag value of 0 if the fragment is the last (“rightmost”) one, else an M flag value of 1. The Identification value generated for the original packet. (3) The fragment itself. The lengths of the fragments must be chosen such that the resulting fragment packets fit within the MTU of the path to the packets' destination(s).
At the destination, fragment packets are reassembled into their original, unfragmented form, as illustrated in
4.6 Destination Options Header The Destination Options header is used to carry optional information that need be examined only by a packet's destination node(s). The Destination Options header is identified by a Next Header value of 60 in the immediately preceding header, and has the format shown in
5. Packet Size Issues IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6. Links that have a configurable MTU (for example, PPP links [RFC-1661]) must be configured to have an MTU of at least 1280 octets; it is recommended that they be configured with an MTU of 1500 octets or greater, to accommodate possible encapsulations (i.e., tunneling) without incurring IPv6-layer fragmentation. From each link to which a node is directly attached, the node must be able to accept packets as large as that link's MTU. It is strongly recommended that IPv6 nodes implement Path MTU Discovery [RFC-1981], in order to discover and take advantage of path MTUs greater than 1280 octets. However, a minimal IPv6 implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 1280 octets, and omit implementation of Path MTU Discovery. In order to send a packet larger than a path's MTU, a node may use the IPv6 Fragment header to fragment the packet at the source and have it reassembled at the destination(s). However, the use of such fragmentation is discouraged in any application that is able to adjust its packets to fit the measured path MTU (i.e., down to 1280 octets). A node must be able to accept a fragmented packet that, after reassembly, is as large as 1500 octets. A node is permitted to accept fragmented packets that reassemble to more than 1500 octets. An upper-layer protocol or application that depends on IPv6 fragmentation to send packets larger than the MTU of a path should not send packets larger than 1500 octets unless it has assurance that the destination is capable of reassembling packets of that larger size. In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used.
6. Flow Labels The 20-bit Flow Label field in the IPv6 header may be used by a source to label sequences of packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or “real-time” service. This aspect of IPv6 is, at the time of writing, still experimental and subject to change as the requirements for flow support in the Internet become clearer. Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, pass the field on unchanged when forwarding a packet, and ignore the field when receiving a packet. Appendix A describes the current intended semantics and usage of the Flow Label field.
7. Traffic Classes The 8-bit Traffic Class field in the IPv6 header is available for use by originating nodes and/or forwarding routers to identify and distinguish between different classes or priorities of IPv6 packets. At the point in time at which this specification is being written, there are a number of experiments underway in the use of the IPv4 Type of Service and/or Precedence bits to provide various forms of “differentiated service” for IP packets, other than through the use of explicit flow set-up. The Traffic Class field in the IPv6 header is intended to allow similar functionality to be supported in IPv6. It is hoped that those experiments will eventually lead to agreement on what sorts of traffic classifications are most useful for IP packets. Detailed definitions of the syntax and semantics of all or some of the IPv6 Traffic Class bits, whether experimental or intended for eventual standardization, are to be provided in separate documents. The following general requirements apply to the Traffic Class field: o The service interface to the IPv6 service within a node must provide a means for an upper-layer protocol to supply the value of the Traffic Class bits in packets originated by that upper-layer protocol. The default value must be zero for all 8 bits. o Nodes that support a specific (experimental or eventual standard) use of some or all of the Traffic Class bits are permitted to change the value of those bits in packets that they originate, forward, or receive, as required for that specific use. Nodes should ignore and leave unchanged any bits of the Traffic Class field for which they do not support a specific use. o An upper-layer protocol must not assume that the value of the Traffic Class bits in a received packet are the same as the value sent by the packet's source.
8. Upper-Layer Protocol Issues 8.1 Upper-Layer Checksums Any transport or other upper-layer protocol that includes the addresses from the IP header in its checksum computation must be modified for use over IPv6, to include the 128-bit IPv6 addresses instead of 32-bit IPv4 addresses. In particular,
Example 2 If an option Y required three data fields, one of length 4 octets, one of length 2 octets, and one of length 1 octet, it would be laid out as shown in
Example 3 A Hop-by-Hop or Destination Options header containing both options X and Y from Examples 1 and 2 would have one of the two formats shown in
Security Considerations The security features of IPv6 are described in the Security Architecture for the Internet Protocol [RFC-2401]. Acknowledgments The authors gratefully acknowledge the many helpful suggestions of the members of the IPng working group, the End-to-End Protocols research group, and the Internet Community At Large. Authors' Addresses Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, Calif. 95134-1706 USA Phone: +1 408 527 8213 Fax: +1 408 527 8254 EMail: deering@cisco.com Robert M. Hinden Nokia 232 Java Drive Sunnyvale, Calif. 94089 USA Phone: +1 408 990-2004 Fax: +1 408 743-5677 EMail: hinden@iprg.nokia.com References [RFC-2401] Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol”, RFC 2401, November 1998. [RFC-2402] Kent, S. and R. Atkinson, “IP Authentication Header”, RFC 2402, November 1998. [RFC-2406] Kent, S. and R. Atkinson, “IP Encapsulating Security Protocol (ESP)”, RFC 2406, November 1998. [ICMPv6] Conta, A. and S. Deering, “ICMP for the Internet Protocol Version 6 (IPv6)”, RFC 2463, December 1998. [ADDRARCH] Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture”, RFC 2373, July 1998. [RFC-1981] McCann, J., Mogul, J. and S. Deering, “Path MTU Discovery for IP version 6”, RFC 1981, August 1996. [RFC-791] Postel, J., “Internet Protocol”, STD 5, RFC 791, September 1981. [RFC-1700] Reynolds, J. and J. Postel, “Assigned Numbers”, STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html [RFC-1661] Simpson, W., “The Point-to-Point Protocol (PPP)”, STD 51, RFC 1661, July 1994. CHANGES SINCE RFC-1883 This memo has the following changes from RFC-1883. Numbers identify the Internet-Draft version in which the change was made. 02) Removed all references to jumbograms and the Jumbo Payload option (moved to a separate document). 02) Moved most of Flow Label description from section 6 to (new) Appendix A. 02) In Flow Label description, now in Appendix A, corrected maximum Flow Label value from FFFFFF to FFFFF (i.e., one less “F”) due to reduction of size of Flow Label field from 24 bits to 20 bits. 02) Renumbered (relettered?) the previous Appendix A to be Appendix B. 02) Changed the wording of the Security Considerations section to avoid dependency loop between this spec and the IPsec specs. 02) Updated R. Hinden's email address and company affiliation. In section 3, changed field name “Class” to “Traffic Class” and increased its size from 4 to 8 bits. Decreased size of Flow Label field from 24 to 20 bits to compensate for increase in Traffic Class field. 01) In section 4.1, restored the order of the Authentication Header and the ESP header, which were mistakenly swapped in the 00 version of this memo. 01) In section 4.4, deleted the Strict/Loose Bit Map field and the strict routing functionality from the Type 0 Routing header, and removed the restriction on number of addresses that may be carried in the Type 0 Routing header (was limited to 23 addresses, because of the size of the strict/loose bit map). 01) In section 5, changed the minimum IPv6 MTU from 576 to 1280 octets, and added a recommendation that links with configurable MTU (e.g., PPP links) be configured to have an MTU of at least 1500 octets. 01) In section 5, deleted the requirement that a node must not send fragmented packets that reassemble to more than 1500 octets without knowledge of the destination reassembly buffer size, and replaced it with a recommendation that upper-layer protocols or applications should not do that. 01) Replaced reference to the IPv4 Path MTU Discovery spec (RFC-1191) with reference to the IPv6 Path MTU Discovery spec (RFC-1981), and deleted the Notes at the end of section 5 regarding Path MTU Discovery, since those details are now covered by RFC-1981. 01) In section 6, deleted specification of “opportunistic” flow set-up, and removed all references to the 6-second maximum lifetime for opportunistically established flow state. 01) In section 7, deleted the provisional description of the internal structure and semantics of the Traffic Class field, and specified that such descriptions be provided in separate documents. In section 4, corrected the Code value to indicate “unrecognized Next Header type encountered” in an ICMP Parameter Problem message (changed from 2 to 1). 00) In the description of the Payload Length field in section 3, and of the Jumbo Payload Length field in section 4.3, made it clearer that extension headers are included in the payload length count. 00) In section 4.1, swapped the order of the Authentication header and the ESP header. (NOTE: this was a mistake, and the change was undone in version 01.) 00) In section 4.2, made it clearer that options are identified by the full 8-bit Option Type, not by the low-order 5 bits of an Option Type. Also specified that the same Option Type numbering space is used for both Hop-by-Hop Options and Destination Options headers. 00) In section 4.4, added a sentence requiring that nodes processing a Routing header must send an ICMP Packet Too Big message in response to a packet that is too big to fit in the next hop link (rather than, say, performing fragmentation). 00) Changed the name of the IPv6 Priority field to “Class”, and replaced the previous description of Priority in section 7 with a description of the Class field. Also, excluded this field from the set of fields that must remain the same for all packets in the same flow, as specified in section 6. 00) In the pseudo-header in section 8.1, changed the name of the “Payload Length” field to “Upper-Layer Packet Length”. Also clarified that, in the case of protocols that carry their own length info (like non-jumbogram UDP), it is the upper-layer-derived length, not the IP-layer-derived length, that is used in the pseudo-header. 00) Added section 8.4, specifying that upper-layer protocols, when responding to a received packet that carried a Routing header, must not include the reverse of the Routing header in the response packet(s) unless the received Routing header was authenticated.
1. Introduction This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. It includes the basic formats for the various types of IPv6 addresses (unicast, anycast, and multicast). The authors would like to acknowledge the contributions of Paul Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, Sue Thomson, Markku Savela, and Larry Masinter.
2. IPv6 Addressing IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces (where “interface” is as defined in section 2 of [IPV6]). There are three types of addresses: Unicast: An identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address. Anycast: An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to an anycast address is delivered to one of the interfaces identified by that address (the “nearest” one, according to the routing protocols' measure of distance). Multicast: An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to a multicast address is delivered to all interfaces identified by that address. There are no broadcast addresses in IPv6, their function being superseded by multicast addresses. In this document, fields in addresses are given a specific name, for example “subnet”. When this name is used with the term “ID” for identifier after the name (e.g., “subnet ID”), it refers to the contents of the named field. When it is used with the term “prefix” (e.g., “subnet prefix”) it refers to all of the address from the left up to and including this field. In IPv6, all zeros and all ones are legal values for any field, unless specifically excluded. Specifically, prefixes may contain, or end with, zero-valued fields. 2.1 Addressing Model IPv6 addresses of all types are assigned to interfaces, not nodes. An IPv6 unicast address refers to a single interface. Since each interface belongs to a single node, any of that node's interfaces' unicast addresses may be used as an identifier for the node. All interfaces are required to have at least one link-local unicast address (see section 2.8 for additional required addresses). A single interface may also have multiple IPv6 addresses of any type (unicast, anycast, and multicast) or scope. Unicast addresses with scope greater than link-scope are not needed for interfaces that are not used as the origin or destination of any IPv6 packets to or from non-neighbors. This is sometimes convenient for point-to-point interfaces. There is one exception to this addressing model: A unicast address or a set of unicast addresses may be assigned to multiple physical interfaces if the implementation treats the multiple physical interfaces as one interface when presenting it to the internet layer. This is useful for load-sharing over multiple physical interfaces. Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link. Multiple subnet prefixes may be assigned to the same link. 2.2 Text Representation of Addresses There are three conventional forms for representing IPv6 addresses as text strings: 1. The preferred form is x:x:x:x:x:x:x:x, where the ‘x’s are the hexadecimal values of the eight 16-bit pieces of the address. Examples: FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 1080:0:0:0:8:800:200C:417A Note that it is not necessary to write the leading zeros in an individual field, but there must be at least one numeral in every field (except for the case described in 2.). 2. Due to some methods of allocating certain styles of IPv6 addresses, it will be common for addresses to contain long strings of zero bits. In order to make writing addresses containing zero bits easier a special syntax is available to compress the zeros. The use of “::” indicates one or more groups of 16 bits of zeros. The “::” can only appear once in an address. The “::” can also be used to compress leading or trailing zeros in an address. For example, the following addresses: 1080:0:0:0:8:800:200C:417A a unicast address FF01:0:0:0:0:0:0:101 a multicast address 0:0:0:0:0:0:0:1 the loopback address 0:0:0:0:0:0:0:0 the unspecified addresses may be represented as: 1080::8:800:200C:417A a unicast address FF01::101 a multicast address ::1 the loopback address :: the unspecified addresses
3. An alternative form that is sometimes more convenient when dealing with a mixed environment of IPv4 and IPv6 nodes is x:x:x:x:x:x:d.d.d.d, where the ‘x’s are the hexadecimal values of the six high-order 16-bit pieces of the address, and the ‘d’s are the decimal values of the four low-order 8-bit pieces of the address (standard IPv4 representation). Examples: 0:0:0:0:0:0:13.1.68.3 0:0:0:0:0:FFFF:129.144.52.38 or in compressed form: ::13.1.68.3::FFFF:129.144.52.38 2.3 Text Representation of Address Prefixes The text representation of IPv6 address prefixes is similar to the way IPv4 addresses prefixes are written in CIDR notation [CIDR]. An IPv6 address prefix is represented by the notation: ipv6-address/prefix-length where ipv6-address is an IPv6 address in any of the notations listed in section 2.2. prefix-length is a decimal value specifying how many of the leftmost contiguous bits of the address comprise the prefix. For example, the following are legal representations of the 60-bit prefix 12AB00000000CD3 (hexadecimal): 12AB:0000:0000:CD30:0000:0000:0000:0000/60 12AB::CD30:0:0:0:0/60 12AB:0:0:CD30::/60 The following are NOT legal representations of the above prefix: 12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros, within any 16-bit chunk of the address 12AB::CD30/60 address to left of “/” expands to 12AB:0000:0000:0000:0000:000:0000:CD30 12AB::CD3/60 address to left of “/” expands to 12AB:0000:0000:0000:0000:000:0000:0CD3 When writing both a node address and a prefix of that node address (e.g., the node's subnet prefix), the two can combined as follows: the node address 12AB:0:0:CD30:123:4567:89AB:CDEF and its subnet number 12AB:0:0:CD30::/60 can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60
2.4 Address Type Identification The type of an IPv6 address is identified by the high-order bits of the address, as shown in
2.5.4 Global Unicast Addresses The general format for IPv6 global unicast addresses is shown in
2.5.5 IPv6 Addresses with Embedded IPv4 Addresses The IPv6 transition mechanisms [TRAN] include a technique for hosts and routers to dynamically tunnel IPv6 packets over IPv4 routing infrastructure. IPv6 nodes that use this technique are assigned special IPv6 unicast addresses that carry a global IPv4 address in the low-order 32 bits. This type of address is termed an “IPv4-compatible IPv6 address” and has the format shown in
2.6.1 Required Anycast Address The Subnet-Router anycast address is predefined. Its format is shown in
The above multicast addresses are reserved and shall never be assigned to any multicast group. All Nodes Addresses: FF01:0:0:0:0:0:0:1 FF02:0:0:0:0:0:0:1 The above multicast addresses identify the group of all IPv6 nodes, within scope 1 (interface-local) or 2 (link-local). All Routers Addresses: FF01:0:0:0:0:0:0:2 FF02:0:0:0:0:0:0:2 FF05:0:0:0:0:0:0:2 The above multicast addresses identify the group of all IPv6 routers, within scope 1 (interface-local), 2 (link-local), or 5 (site-local). Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX Solicited-node multicast address are computed as a function of a node's unicast and anycast addresses. A solicited-node multicast address is formed by taking the low-order 24 bits of an address (unicast or anycast) and appending those bits to the prefix FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the range FF02:0:0:0:0:1:FF00:0000 to FF02:0:0:0:0:1:FFFF:FFFF For example, the solicited node multicast address corresponding to the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 addresses that differ only in the high-order bits, e.g., due to multiple high-order prefixes associated with different aggregations, will map to the same solicited-node address thereby, reducing the number of multicast addresses a node must join. A node is required to compute and join (on the appropriate interface) the associated Solicited-Node multicast addresses for every unicast and anycast address it is assigned. 2.8 A Node's Required Addresses A host is required to recognize the following addresses as identifying itself: o Its required Link-Local Address for each interface. o Any additional Unicast and Anycast Addresses that have been configured for the node's interfaces (manually or automatically). o The loopback address. o The All-Nodes Multicast Addresses defined in section 2.7.1. o The Solicited-Node Multicast Address for each of its unicast and anycast addresses. o Multicast Addresses of all other groups to which the node belongs. A router is required to recognize all addresses that a host is required to recognize, plus the following addresses as identifying itself: o The Subnet-Router Anycast Addresses for all interfaces for which it is configured to act as a router. o All other Anycast Addresses with which the router has been configured. o The All-Routers Multicast Addresses defined in section 2.7.1. 3. Security Considerations IPv6 addressing documents do not have any direct impact on Internet infrastructure security. Authentication of IPv6 packets is defined in [AUTH].
4. IANA Considerations The table and notes at http://www.isi.edu/in-notes/iana/assignments/ipv6-address-space.txt should be replaced with the following: INTERNET PROTOCOL VERSION 6 ADDRESS SPACE The initial assignment of IPv6 address space is shown in
5. References 5.1 Normative References [IPV6] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 2460, December 1998. [RFC2026] Bradner, S., “The Internet Standards Process—Revision 3”, BCP 9, RFC 2026, October 1996. 5.2 Informative References [ANYCST] Partridge, C., Mendez, T. and W. Milliken, “Host Anycasting Service”, RFC 1546, November 1993. [AUTH] Kent, S. and R. Atkinson, “IP Authentication Header”, RFC 2402, November 1998. [AGGR] Hinden, R., O'Dell, M. and S. Deering, “An Aggregatable Global Unicast Address Format”, RFC 2374, July 1998. [CIDR] Fuller, V., Li, T., Yu, J. and K. Varadhan, “Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy”, RFC 1519, September 1993. [ETHER] Crawford, M., “Transmission of IPv6 Packets over Ethernet Networks”, RFC 2464, December 1998. [EUI64] IEEE, “Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority”, http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. [FDDI] Crawford, M., “Transmission of IPv6 Packets over FDDI Networks”, RFC 2467, December 1998. [MASGN] Hinden, R. and S. Deering, “IPv6 Multicast Address Assignments”, RFC 2375, July 1998. [NSAP] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J. and A. Lloyd, “OSI NSAPs and IPv6”, RFC 1888, August 1996. [PRIV] Narten, T. and R. Draves, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6”, RFC 3041, January 2001. [TOKEN] Crawford, M., Narten, T. and S. Thomas, “Transmission of IPv6 Packets over Token Ring Networks”, RFC 2470, December 1998. [TRAN] Gilligan, R. and E. Nordmark, “Transition Mechanisms for IPv6 Hosts and Routers”, RFC 2893, August 2000. APPENDIX A: Creating Modified EUI-64 format Interface Identifiers Depending on the characteristics of a specific link or node there are a number of approaches for creating Modified EUI-64 format interface identifiers. This appendix describes some of these approaches. Links or Nodes with IEEE EUI-64 Identifiers The only change needed to transform an IEEE EUI-64 identifier to an interface identifier is to invert the “u” (universal/local) bit. For example, a globally unique IEEE EUI-64 identifier of the form is shown in
1. Introduction Internet Protocol version 6 includes support for addresses of different “scope”; that is, both global and non-global (e.g., link-local) addresses. Although non-global addressing has been introduced operationally in the IPv4 Internet, both in the use of private address space (“net 10”, etc.) and with administratively scoped multicast addresses, the design of IPv6 formally incorporates the notion of address scope into its base architecture. This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. Though the current address architecture specification [1] defines unicast site-local addresses, the IPv6 working group decided to deprecate the syntax and the usage [5] and is now investigating other forms of local IPv6 addressing. The usage of any new forms of local addresses will be documented elsewhere in the future. Thus, this document intentionally focuses on link-local and multicast scopes only.
2. Definitions The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [2].
3. Basic Terminology The terms link, interface, node, host, and router are defined in [3]. The definitions of unicast address scopes (link-local and global) and multicast address scopes (interface-local, link-local, etc.) are contained in [1].
4. Address Scope Every IPv6 address other than the unspecified address has a specific scope; that is, a topological span within which the address may be used as a unique identifier for an interface or set of interfaces. The scope of an address is encoded as part of the address, as specified in [1]. For unicast addresses, this document discusses two defined scopes: o Link-local scope, for uniquely identifying interfaces within (i.e., attached to) a single link only. o Global scope, for uniquely identifying interfaces anywhere in the Internet. The IPv6 unicast loopback address, ::1, is treated as having link-local scope within an imaginary link to which a virtual “loopback interface” is attached. The unspecified address, ::, is a special case. It does not have any scope because it must never be assigned to any node according to [1]. Note, however, that an implementation might use an implementation dependent semantics for the unspecified address and may want to allow the unspecified address to have specific scopes. For example, implementations often use the unspecified address to represent “any” address in APIs. In this case, implementations may regard the unspecified address with a given particular scope as representing the notion of “any address in the scope”. This document does not prohibit such a usage, as long as it is limited within the implementation. [1] defines IPv6 addresses with embedded IPv4 addresses as being part of global addresses. Thus, those addresses have global scope, with regard to the IPv6 scoped address architecture. However, an implementation may use those addresses as if they had other scopes for convenience. For instance, [6] assigns link-local scope to IPv4 auto-configured link-local addresses (the addresses from the prefix 169.254.0.0/16 [7]) and converts those addresses into IPv4-mapped IPv6 addresses in order to perform destination address selection among IPv4 and IPv6 addresses. This would implicitly mean that the IPv4-mapped IPv6 addresses equivalent to the IPv4 auto-configuration link-local addresses have link-local scope. This document does not preclude such a usage, as long as it is limited within the implementation. Anycast addresses [1] are allocated from the unicast address space and have the same scope properties as unicast addresses. All statements in this document regarding unicast apply equally to anycast. For multicast addresses, there are fourteen possible scopes, ranging from interface-local to global (including link-local). The interface-local scope spans a single interface only; a multicast address of interface-local scope is useful only for loopback delivery of multicasts within a single node; for example, as a form of inter-process communication within a computer. Unlike the unicast loopback address, interface-local multicast addresses may be assigned to any interface. There is a size relationship among scopes: o For unicast scopes, link-local is a smaller scope than global. o For multicast scopes, scopes with lesser values in the “scop” subfield of the multicast address (Section 2.7 of [1]) are smaller than scopes with greater values, with interface-local being the smallest and global being the largest. However, two scopes of different size may cover the exact same region of topology. For example, a (multicast) site may consist of a single link, in which both link-local and site-local scope effectively cover the same topological span.
5. Scope Zones A scope zone, or simply a zone, is a connected region of topology of a given scope. For example, the set of links connected by routers within a particular (multicast) site, and the interfaces attached to those links, comprise a single zone of multicast site-local scope. Note that a zone is a particular instance of a topological region (e.g., Alice's site or Bob's site), whereas a scope is the size of a topological region (e.g., a site or a link). The zone to which a particular non-global address pertains is not encoded in the address itself but determined by context, such as the interface from which it is sent or received. Thus, addresses of a given (non-global) scope may be re-used in different zones of that scope. For example, two different physical links may each contain a node with the link-local address fe80::1. Zones of the different scopes are instantiated as follows: o Each interface on a node comprises a single zone of interface-local scope (for multicast only). o Each link and the interfaces attached to that link comprise a single zone of link-local scope (for both unicast and multicast). o There is a single zone of global scope (for both unicast and multicast) comprising all the links and interfaces in the Internet. o The boundaries of zones of a scope other than interface-local, link-local, and global must be defined and configured by network administrators. Zone boundaries are relatively static features, not changing in response to short-term changes in topology. Thus, the requirement that the topology within a zone be “connected” is intended to include links and interfaces that may only be occasionally connected. For example, a residential node or network that obtains Internet access by dial-up to an employer's (multicast) site may be treated as part of the employer's (multicast) site-local zone even when the dial-up link is disconnected. Similarly, a failure of a router, interface, or link that causes a zone to become partitioned does not split that zone into multiple zones. Rather, the different partitions are still considered to belong to the same zone. Zones have the following additional properties: o Zone boundaries cut through nodes, not links. (Note that the global zone has no boundary, and the boundary of an interface-local zone encloses just a single interface.) o Zones of the same scope cannot overlap; i.e., they can have no links or interfaces in common. o A zone of a given scope (less than global) falls completely within zones of larger scope. That is, a smaller scope zone cannot include more topology than would any larger scope zone with which it shares any links or interfaces. o Each zone is required to be “convex” from a routing perspective; i.e., packets sent from one interface to any other in the same zone are never routed outside the zone. Note, however, that if a zone contains a tunneled link (e.g., an IPv6-over-IPv6 tunnel link [8]), a lower layer network of the tunnel can be located outside the zone without breaking the convexity property. Each interface belongs to exactly one zone of each possible scope. Note that this means that an interface belongs to a scope zone regardless of what kind of unicast address the interface has or of which multicast groups the node joins on the interface.
6. Zone Indices Because the same non-global address may be in use in more than one zone of the same scope (e.g., the use of link-local address fe80::1 in two separate physical links) and a node may have interfaces attached to different zones of the same scope (e.g., a router normally has multiple interfaces attached to different links), a node requires an internal means to identify to which zone a non-global address belongs. This is accomplished by assigning, within the node, a distinct “zone index” to each zone of the same scope to which that node is attached, and by allowing all internal uses of an address to be qualified by a zone index. The assignment of zone indices is illustrated in
7. Sending Packets When an upper-layer protocol sends a packet to a non-global destination address, it must have a means of identifying the intended zone to the IPv6 layer for cases in which the node is attached to more than one zone of the destination address's scope. Although identification of an outgoing interface is sufficient to identify an intended zone (because each interface is attached to no more than one zone of each scope), in many cases that is more specific than desired. For example, when sending to a link-local unicast address from a node that has more than one interface to the intended link (an unusual configuration), the upper layer protocol may not care which of those interfaces is used for the transmission. Rather, it would prefer to leave that choice to the routing function in the IP layer. Thus, the upper-layer requires the ability to specify a zone index, when sending to a non-global, non-loopback destination address.
8. Receiving Packets When an upper-layer protocol receives a packet containing a non-global source or destination address, the zone to which that address pertains can be determined from the arrival interface, because the arrival interface can be attached to only one zone of the same scope as that of the address under consideration. However, it is recommended that the IP layer convey to the upper layer the correct zone indices for the arriving source and destination addresses, in addition to the arrival interface identifier.
9. Forwarding When a router receives a packet addressed to a node other than itself, it must take the zone of the destination and source addresses into account as follows: o The zone of the destination address is determined by the scope of the address and arrival interface of the packet. The next-hop interface is chosen by looking up the destination address in a (conceptual) routing table specific to that zone (see Section 10). That routing table is restricted to refer to interfaces belonging to that zone. o After the next-hop interface is chosen, the zone of the source address is considered. As with the destination address, the zone of the source address is determined by the scope of the address and arrival interface of the packet. If transmitting the packet on the chosen next-hop interface would cause the packet to leave the zone of the source address, i.e., cross a zone boundary of the scope of the source address, then the packet is discarded. Additionally, if the packet's destination address is a unicast address, an ICMP Destination Unreachable message [4] with Code 2 (“beyond scope of source address”) is sent to the source of the original packet. Note that Code 2 is currently left as unassigned in [4], but the IANA will re-assign the value for the new purpose, and [4] will be revised with this change. Note that even if unicast site-local addresses are deprecated, the above procedure still applies to link-local addresses. Thus, if a router receives a packet with a link-local destination address that is not one of the router's own link-local addresses on the arrival link, the router is expected to try to forward the packet to the destination on that link (subject to successful determination of the destination's link-layer address via the Neighbor Discovery protocol [9]). The forwarded packet may be transmitted back through the arrival interface, or through any other interface attached to the same link. A node that receives a packet addressed to itself and containing a Routing Header with more than zero Segments Left (Section 4.4 of [3]) first checks the scope of the next address in the Routing Header. If the scope of the next address is smaller than the scope of the original destination address, the node MUST discard the packet. Otherwise, it swaps the original destination address with the next address in the Routing Header. Then the above forwarding rules apply as follows: o The zone of the new destination address is determined by the scope of the next address and the arrival interface of the packet. The next-hop interface is chosen as per the first bullet of the rules above. o After the next-hop interface is chosen, the zone of the source address is considered as per the second bullet of the rules above. This check about the scope of the next address ensures that when a packet arrives at its final destination, if that destination is link-local, then the receiving node can know that the packet originated on-link. This will help the receiving node send a “response” packet with the final destination of the received packet as the source address without breaking its source zone. Note that it is possible, though generally inadvisable, to use a Routing Header to convey a non-global address across its associated zone boundary in the previously used next address field. For example, consider a case in which a link-border node (e.g., a router) receives a packet with the destination being a link-local address, and the source address a global address. If the packet contains a Routing Header where the next address is a global address, the next-hop interface to the global address may belong to a different link than that of the original destination. This is allowed because the scope of the next address is not smaller than the scope of the original destination.
10. Routing Note that as unicast site-local addresses are deprecated, and link-local addresses do not need routing, the discussion in this section only applies to multicast scoped routing. When a routing protocol determines that it is operating on a zone boundary, it MUST protect inter-zone integrity and maintain intra-zone connectivity. To maintain connectivity, the routing protocol must be able to create forwarding information for the global groups and for all the scoped groups for each of its attached zones. The most straightforward way of doing this is to create (conceptual) forwarding tables for each specific zone. To protect inter-zone integrity, routers must be selective in the group information shared with neighboring routers. Routers routinely exchange routing information with neighboring routers. When a router is transmitting this routing information, it must not include any information about zones other than the zones assigned to the interface used to transmit the information. As an example, the router in
11. Textual Representation As already mentioned, to specify an IPv6 non-global address without ambiguity, an intended scope zone should be specified as well. As a common notation to specify the scope zone, an implementation SHOULD support the following format: <address>%<zone_id> where <address> is a literal IPv6 address, <zone_id> is a string identifying the zone of the address, and ‘%’ is a delimiter character to distinguish between <address> and <zone_id>. The following subsections describe detailed definitions, concrete examples, and additional notes of the format. 11.1. Non-Global Addresses The format applies to all kinds of unicast and multicast addresses of non-global scope except the unspecified address, which does not have a scope. The format is meaningless and should not be used for global addresses. The loopback address belongs to the trivial link; i.e., the link attached to the loopback interface. Thus the format should not be used for the loopback address, either. This document does not specify the usage of the format when the <address> is the unspecified address, as the address does not have a scope. This document, however, does not prohibit an implementation from using the format for those special addresses for implementation dependent purposes. 11.2. The <zone_id> Part In the textual representation, the <zone_id> part should be able to identify a particular zone of the address's scope. Although a zone index is expected to contain enough information to determine the scope and to be unique among all scopes as described in Section 6, the <zone_id> part of this format does not have to contain the scope. This is because the <address> part should specify the appropriate scope. This also means that the <zone_id> part does not have to be unique among all scopes. With this loosened property, an implementation can use a convenient representation as <zone_id>. For example, to represent link index 2, the implementation can simply use “2” as <zone_id>, which would be more readable than other representations that contain the “link” scope. When an implementation interprets the format, it should construct the “full” zone index, which contains the scope, from the <zone_id> part and the scope specified by the <address> part. (Remember that a zone index itself should contain the scope, as specified in Section 6.) An implementation SHOULD support at least numerical indices that are non-negative decimal integers as <zone_id>. The default zone index, which should typically be 0 (see Section 6), is included in the integers. When <zone_id> is the default, the delimiter characters “%” and <zone_id> can be omitted. Similarly, if a textual representation of an IPv6 address is given without a zone index, it should be interpreted as <address>%<default ID>, where <default ID> is the default zone index of the scope that <address> has. An implementation MAY support other kinds of non-null strings as <zone_id>. However, the strings must not conflict with the delimiter character. The precise format and semantics of additional strings is implementation dependent. One possible candidate for these strings would be interface names, as interfaces uniquely disambiguate any scopes. In particular, interface names can be used as “default identifiers” for interfaces and links, because by default there is a one-to-one mapping between interfaces and each of those scopes as described in Section 6. An implementation could also use interface names as <zone_id> for scopes larger than links, but there might be some confusion in this use. For example, when more than one interface belongs to the same (multicast) site, a user would be confused about which interface should be used. Also, a mapping function from an address to a name would encounter the same kind of problem when it prints an address with an interface name as a zone index. This document does not specify how these cases should be treated and leaves it implementation dependent. It cannot be assumed that indices are common across all nodes in a zone (see Section 6). Hence, the format MUST be used only within a node and MUST NOT be sent on the wire unless every node that interprets the format agrees on the semantics. 11.3. Examples The following addresses fe80::1234 (on the 1st link of the node) ff02::5678 (on the 5th link of the node) ff08::9abc (on the 10th organization of the node) would be represented as follows: fe80::1234%1 ff02::5678%5 ff08::9abc%10 (Here we assume a natural translation from a zone index to the <zone_id> part, where the Nth zone of any scope is translated into “N”.) If we use interface names as <zone_id>, those addresses could also be represented as follows: fe80:1 234% ne0 ff02::5678%pvc1.3 ff08::9abc%interface10 where the interface “ne0” belongs to the 1st link, “pvc1.3” belongs to the 5th link, and “interface10” belongs to the 10th organization. 11.4. Usage Examples Applications that are supposed to be used in end hosts such as telnet, ftp, and ssh may not explicitly support the notion of address scope, especially of link-local addresses. However, an expert user (e.g., a network administrator) sometimes has to give even link-local addresses to such applications. Here is a concrete example. Consider a multi-linked router called “R1” that has at least two point-to-point interfaces (links). Each of the interfaces is connected to another router, “R2” and “R3”, respectively. Also assume that the point-to-point interfaces have link-local addresses only. Now suppose that the routing system on R2 hangs up and has to be reinvoked. In this situation, we may not be able to use a global address of R2, because this is routing trouble and we cannot expect to have enough routes for global reachability to R2. Hence, we have to login R1 first and then try to login R2 by using link-local addresses. In this case, we have to give the link-local address of R2 to, for example, telnet. Here we assume the address is fe80::2. Note that we cannot just type % telnet fe80::2 here, since R1 has more than one link and hence the telnet command cannot detect which link it should try to use for connecting. Instead, we should type the link-local address with the link index as follows: % telnet fe80::2%3 where “3” after the delimiter character ‘%’ corresponds to the link index of the point-to-point link. 11.5. Related API An extension to the recommended basic API defines how the format for non-global addresses should be treated in library functions that translate a nodename to an address, or vice versa [11]. 11.6. Omitting Zone Indices The format defined in this document does not intend to invalidate the original format for non-global addresses; that is, the format without the zone index portion. As described in Section 6, in some common cases with the notion of the default zone index, there can be no ambiguity about scope zones. In such an environment, the implementation can omit the “%<zone_id>” part. As a result, it can act as though it did not support the extended format at all. 11.7. Combinations of Delimiter Characters There are other kinds of delimiter characters defined for IPv6 addresses. In this subsection, we describe how they should be combined with the format for non-global addresses. The IPv6 addressing architecture [1] also defines the syntax of IPv6 prefixes. If the address portion of a prefix is non-global and its scope zone should be disambiguated, the address portion SHOULD be in the format. For example, a link-local prefix fe80::/64 on the second link can be represented as follows: fe80::%2/64 In this combination, it is important to place the zone index portion before the prefix length when we consider parsing the format by a name-to-address library function [11]. That is, we can first separate the address with the zone index from the prefix length, and just pass the former to the library function. The preferred format for literal IPv6 addresses in URLs is also defined [12]. When a user types the preferred format for an IPv6 non-global address whose zone should be explicitly specified, the user could use the format for the non-global address combined with the preferred format. However, the typed URL is often sent on the wire, and it would cause confusion if an application did not strip the <zone_id> portion before sending. Note that the applications should not need to care about which kind of addresses they're using, much less parse or strip out the <zone_id> portion of the address. Also, the format for non-global addresses might conflict with the URI syntax [13], since the syntax defines the delimiter character (‘%’) as the escape character. This conflict would require, for example, that the <zone_id> part for zone 1 with the delimiter be represented as ‘%251’. It also means that we could not simply copy a non-escaped format from other sources as input to the URI parser. Additionally, if the URI parser does not convert the escaped format before passing it to a name-to-address library, the conversion will fail. All these issues would decrease the benefit of the textual representation described in this section. Hence, this document does not specify how the format for non-global addresses should be combined with the preferred format for literal IPv6 addresses. In any case, it is recommended to use an FQDN instead of a literal IPv6 address in a URL, whenever an FQDN is available.
12. Security Considerations A limited scope address without a zone index has security implications and cannot be used for some security contexts. For example, a link-local address cannot be used in a traffic selector of a security association established by Internet Key Exchange (IKE) when the IKE messages are carried over global addresses. Also, a link-local address without a zone index cannot be used in access control lists. The routing section of this document specifies a set of guidelines whereby routers can prevent zone-specific information from leaking out of each zone. If, for example, multicast site boundary routers allow site routing information to be forwarded outside of the site, the integrity of the site could be compromised. Since the use of the textual representation of non-global addresses is restricted to use within a single node, it does not create a security vulnerability from outside the node. However, a malicious node might send a packet that contains a textual IPv6 non-global address with a zone index, intending to deceive the receiving node about the zone of the non-global address. Thus, an implementation should be careful when it receives packets that contain textual non-global addresses as data.
13. Contributors This document is a combination of several separate efforts. Atsushi Onoe took a significant role in one of them and deeply contributed to the content of Section 11 as a co-author of a separate proposal.
14. Acknowledgements Many members of the IPv6 working group provided useful comments and feedback on this document. In particular, Margaret Wasserman and Bob Hinden led the working group to make a consensus on IPv6 local addressing. Richard Draves proposed an additional rule to process Routing header containing scoped addresses. Dave Thaler and Francis Dupont gave valuable suggestions to define semantics of zone indices in terms of related API. Pekka Savola reviewed a version of the document very carefully and made detailed comments about serious problems. Steve Bellovin, Ted Hardie, Bert Wijnen, and Timothy Gleeson reviewed and helped improve the document during the preparation for publication.
15. References 15.1. Normative References [1] Hinden, R. and S. Deering, “Internet Protocol Version 6 (IPv6) Addressing Architecture”, RFC 3513, April 2003. [2] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997. [3] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 2460, December 1998. [4] Conta, A. and S. Deering, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification”, RFC 2463, December 1998. 15.2. Informative References [5] Huitema, C. and B. Carpenter, “Deprecating Site Local Addresses”, RFC 3879, September 2004. [6] Draves, R., “Default Address Selection for Internet Protocol version 6 (IPv6)”, RFC 3484, February 2003. [7] Cheshire, S., Aboba, B., and E. Guttman, “Dynamic Configuration of Link-Local IPv4 Addresses”, Work in Progress. [8] Conta, A. and S. Deering, “Generic Packet Tunneling in IPv6 Specification”, RFC 2473, December 1998. [9] Narten, T., Nordmark, E., and W. Simpson, “Neighbor Discovery for IP Version 6 (IPv6)”, RFC 2461, December 1998. [10] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, “Basic Socket Interface Extensions for IPv6”, RFC 3493, February 2003. [11] Gilligan, R., “Scoped Address Extensions to the IPv6 Basic Socket API”, Work in Progress, July 2002. [12] Hinden, R., Carpenter, B., and L. Masinter, “Format for Literal IPv6 Addresses in URL's”, RFC 2732, December 1999. [13] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax”, RFC 3986, January 2005.
To the accomplishment of the foregoing and related ends, the descriptions and annexed drawings set forth certain illustrative aspects and implementations of the disclosure. These are indicative of but a few of the various ways in which one or more aspects of the disclosure may be employed. The other aspects, advantages, and novel features of the disclosure will become apparent from the detailed description included herein when considered in conjunction with the annexed drawings.
It should be understood that the various components illustrated in the various block diagrams represent logical components that operate to perform the functionality described herein and may be implemented in software, hardware, or a combination of the two. While at least one of these components are implemented at least partially as an electronic hardware component, and therefore constitutes a machine, the other components may be implemented in software that when included in an execution environment constitutes a machine, hardware, or a combination of software and hardware.
More particularly, at least one component defined by the claims is implemented at least partially as an electronic hardware component, such as an instruction execution machine (e.g., a processor-based or processor-containing machine) and/or as specialized circuits or circuitry (e.g., discreet logic gates interconnected to perform a specialized function). Other components may be implemented in software, hardware, or a combination of software and hardware. Moreover, some or all of these other components may be combined, some may be omitted altogether, and additional components may be added while still achieving the functionality described herein. Thus, the subject matter described herein may be embodied in many different variations, and all such variations are contemplated to be within the scope of what is claimed.
In the description above, the subject matter is described with reference to acts and symbolic representations of operations that are performed by one or more devices, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processor of data in a structured form. This manipulation transforms the data or maintains it at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the device in a manner well understood by those skilled in the art. The data is maintained at physical locations of the memory as data structures that have particular properties defined by the format of the data. However, while the subject matter is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that various of the acts and operation described hereinafter may also be implemented in hardware.
To facilitate an understanding of the subject matter described above, many aspects are described in terms of sequences of actions that may be performed by elements of a computer system. For example, it will be recognized that the various actions may be performed by specialized circuits or circuitry (e.g., discrete logic gates interconnected to perform a specialized function), by program instructions being executed by one or more processors, or by a combination of both. The description herein of any sequence of actions is not intended to imply that the specific order described for performing that sequence must be followed.
Moreover, the methods described herein may be embodied in executable instructions stored in a computer readable medium for use by or in connection with an instruction execution machine, system, apparatus, or device, such as a computer-based or processor-containing machine, system, apparatus, or device. As used here, a “computer readable medium” may include one or more of any suitable media for storing the executable instructions of a software component in one or more forms including an electronic, magnetic, optical, and electromagnetic form, such that the instruction execution machine, system, apparatus, or device may read (or fetch) the instructions from the non-transitory computer readable medium and execute the instructions for carrying out the described methods. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, software components or other data. Computer storage media includes, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM); Electrically Erasable Programmable Read Only Memory (EEPROM); flash memory or other memory technology; portable computer diskette; Compact Disk Read Only Memory (CDROM), compact disc-rewritable (CDRW), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by an execution environment.
Communication media typically embodies computer readable instructions, data structures, software components, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
Thus, the subject matter described herein may be embodied in many different forms, and all such forms are contemplated to be within the scope of what is claimed. It will be understood that various details may be changed without departing from the scope of the claimed subject matter.
The use of the terms “a” and “a” and “the” and similar referents in the context of describing the subject matter (particularly in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the scope of protection sought is defined by the claims as set forth hereinafter together with any equivalents thereof entitled to. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illustrate the subject matter and does not pose a limitation on the scope of the subject matter unless otherwise claimed. The use of the term “based on” and other like phrases indicating a condition for bringing about a result, both in the claims and in the written description, is not intended to foreclose any other conditions that bring about that result. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention as claimed.
The use of “including”, “comprising”, “having”, and variations thereof are meant to encompass the items listed thereafter and equivalents thereof as well as additional items and equivalents thereof. Terms used to describe interoperation and/or coupling between components are intended to include both direct and indirect interoperation and/or coupling, unless otherwise indicated. Exemplary terms used in describing interoperation and/or coupling include “mounted,” “connected,” “attached,” “coupled,” “communicatively coupled,” “operatively coupled,” “invoked”, “called”, “provided to”, “received from”, “identified to”, “interoperated” and similar terms and their variants.
As used herein, any reference to an entity “in” an association is equivalent to describing the entity as “included in and/or identified by” the association, unless explicitly indicated otherwise.
Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. Although methods, components, and devices similar or equivalent to those described herein can be used in the practice or testing of the subject matter described herein, suitable methods, components, and devices are described below.
All publications, patent applications, patents, and other references mentioned herein are incorporated by reference in their entirety, unless explicitly stated otherwise. In case of conflict, the present disclosure, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and not intended to be limiting.
It is unlikely that the designers of the early network, which is referred to as the “Internet”, expected it to become as large as it has become. The fact that the global Internet Protocol (IP) address space, for 32-bit addresses, has been fully allocated is evidence of this. As the Internet grows, new problems will arise and some current problems are getting worse. For example, while network speeds and bandwidth are increasing, so are causes of network latency.
The Internet Engineering Task Force (IETF) has taken steps at various times in the past and are presently taking steps to address a number of problems resulting from the Internet's growth. Problems addressed by the IETF are described in a number of “Request for Comments” (RFC) documents published by the IETF. Documents referenced herein and included by reference include: “Request for Comments” (RFC) document RFC 791 edited by J. Postel, titled “Internet Protocol, DARPA Internet Protocol Specification”, published by the IETF in September, 1981;
“Request for Comments” (RFC) document RFC 1519 by V. Fuller, et al, titled “Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy”, published by the Internet Engineering Task Force (IEFT), in June, 1999;
“Request for Comments” (RFC) document RFC 2460 by S. Deering, et al, titled “Internet Protocol, Version 6, (IPv6) Specification”, published by the IETF in December, 1998;
“Request for Comments” (RFC) document RFC 3513 by R. Hinden, et al, titled “Internet Protocol Version 6 (IPv6) Addressing Architecture”, published by the IETF in April, 2003; and
“Request for Comments” (RFC) document RFC 2374 by R. Hinden, et al, titled “Aggregatable Global Unicast Address Format”, published by the IETF in July, 1998.
RFC 791 states, “The internet protocol implements two basic functions: addressing and fragmentation”. RFC 791 goes on to state, “A distinction is made between names, addresses, and routes. A name indicates what we seek. An address indicates where it is. A route indicates how to get there. The internet protocol deals primarily with addresses. It is the task of higher level (i.e., host-to-host or application) protocols to make the mapping from names to addresses. The internet module maps internet addresses to local net addresses. It is the task of lower level (i.e., local net or gateways) procedures to make the mapping from local net addresses to routes”.
As demonstrated by the RFCs listed above addressing has been a source of a number of problems. In order to address a number of current and future problems facing the Internet, the subject matter described herein challenges the distinctions asserted in RFC 791 and establishes new relationships between and among names, addresses, and routes. The description herein further demonstrates that current internet addresses do not indicate where a node or network interface component (NIC) of a node is. They provide another global identifier space for identifying nodes and their network interfaces. This global identifier space, to some extent, is duplicative of the domain name space that is also a global identifier space for identifying nodes and network interfaces. This duplication of roles is unnecessary as described below.
All publications, patent applications, patents, and other references mentioned herein are incorporated by reference in their entirety. In case of conflict, the present disclosure, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and not intended to be limiting.
The present application is a continuation of U.S. application Ser. No. 14/274,632 (published US 2014-0365682 A1) filed May 9, 2014 and entitled “Methods, Systems, and Computer Program Products for Associating a Name with a Network Path” which, in turn, is a continuation-in-part of and claims priority to: U.S. application Ser. No. 13/727,647 (published US 2014-0189152 A1) filed Dec. 27, 2012 and entitled “Methods, Systems, and Computer Program Products for Identifying a Protocol Address based on Path Information,” U.S. application Ser. No. 13/727,649 (published US 2014-0189081 A1) filed Dec. 27, 2012 and entitled “Methods, Systems, and Computer Program Products for Assigning an Interface Identifier to a Network Interface,” U.S. application Ser. No. 13/727,651 (published US 2014-0189045 A1) filed Dec. 27, 2012 and entitled “Methods, Systems, and Computer Program Products for Routing Based on a Nested Protocol Address,” U.S. application Ser. No. 13/727,652 (published US 2014-0189153 A1) filed Dec. 27, 2012 and entitled “Methods, Systems, and Computer Program Products for Routing Based on a Scope-Specific Address,” U.S. application Ser. No. 13/727,653 (published US 2014-0189159 A1) filed Dec. 27, 2012 and entitled “Methods, Systems, and Computer Program Products for Identifying a Protocol Address in a Scope-Specific Address Space,” U.S. application Ser. No. 13/727,655 (published US 2014-0189154 A1) filed Dec. 27, 2012 and entitled “Methods, Systems, and Computer Program Products for Determining a Shared Identifier for a Hop in a Network,” U.S. application Ser. No. 13/727,657 (published US 2014-0189155 A1) filed Dec. 27, 2012 and entitled “Methods, Systems, and Computer Program Products for Determining a Protocol Address For a Node,” and U.S. application Ser. No. 13/727,662 (published US 2014-0189156 A1) filed Dec. 27, 2012 and entitled “Methods, Systems, and Computer Program Products for Routing Based on a Path-Based Protocol Address,” where U.S. application Ser. No. 14/274,632 further claims priority to U.S. Provisional Application No. 61/822,978 filed May 14, 2013 and entitled “Methods, Systems, and Computer Program Products For Transmitting Data Via A Scope-Specific Protocol Address,” U.S. Provisional Application No. 61/822,386 filed May 12, 2013 and entitled “Methods, Systems, and Computer Program Products For Associating a Name With a Network Path,” U.S. Provisional Application No. 61/897,234 filed Oct. 30, 2013 and entitled “Methods, Systems, and Computer Program Products For Transmitting Data Via A Variable Length Protocol Address,” U.S. Provisional Application No. 61/830,064 filed Jun. 1, 2013 and entitled “Methods, Systems, and Computer Program Products For Adjusting A Separator Field For A Protocol Address,” U.S. Provisional Application No. 61/831,932 filed Jun. 6, 2013 and entitled “Methods, Systems, and Computer Program Products for Source Routing,” and U.S. Provisional Application No. 61/833,565 filed Jun. 11, 2013 and entitled “Methods, Systems, and Computer Program Products For Changing Protocol Address By A Network Relay,” the entire contents of all of the above are herein incorporated by reference. This application is related to the following currently pending U.S. Patent Applications by the present inventor, the entire disclosures of each being incorporated by reference herein: application Ser. No. 11/962,285 (published US 2009-0161576 A1), filed on 2007 Dec. 21, entitled “Methods and Systems for Sending Information to a Zone Included in an Internet Network”; Application Ser. No. 12/062,101 (published US 2009-0252161 A1), filed on 2008 Apr. 3, entitled “Methods and Systems for Routing a Data Packet Based on Geospatial Information”; Application Ser. No. 12/170,833 (published US 2010-0010975 A1), filed on 2008 Jul. 10, entitled “Methods and Systems for Resolving a Query Region to a Network Identifier”; Application Ser. No. 12/170,829 (published US 2010-0010992 A1), filed on 2008 Jul. 10, entitled “Methods and Systems for Resolving a Location Information to a Network Identifier”; Application Ser. No. 12/170,821 (published US 2010-0011048 A1), filed on 2008 Jul. 10, entitled “Methods and Systems for Resolving a Geospatial Query Region to a Network Identifier”; Application Ser. No. 12/272,989 (published US 2010-0124220 A1), by the present inventor, filed on 2008 Nov. 18, entitled “Methods and Systems for Incrementally Resolving a Host Name to a Protocol address”; Application Ser. No. 12/328,059 (published US 2010-0142401 A1), filed on 2008 Dec. 4, entitled “Methods, Systems, and Computer Program Products for Determining a Network Identifier of a Node Providing a Type of Service for a Geospatial Region”; Application Ser. No. 12/328,038 (published US 2010-0145602 A1), filed on 2008 Dec. 4, entitled “Methods, Systems, and Computer Program Products for Associating Resources of a First Geospace with a Second Geospace”; Application Ser. No. 12/328,048 (published US 2010-0145963 A1), filed on 2008 Dec. 4, entitled “Methods, Systems, and Computer Program Products for Resolving a Network Identifier Based on a Geospatial Domain Space Harmonized with a Non-Geospatial Domain Space” Application Ser. No. 12/328,063 (published US 2010-0146132 A1), filed on 2008 Dec. 4, entitled “Methods, Systems, and Computer Program Products for Accessing a Resource Having a Protocol address Associated With a Location on a Map”; Application Ser. No. 12/339,675 (published US 2010-0161732 A1), filed on 2008 Dec. 19, entitled “Methods, Systems, and Computer Program Products for Maintaining Consistency Between Non-Geospatial and Geospatial Address space directories”; Application Ser. No. 12/401,707 (published US 2010-0232433 A1), filed on 2009 Mar. 11, entitled “Methods and Systems for Resolving a Source node Identifier in a First Identifier Domain Space to a Second Node Identifier in a Second Identifier Domain Space”; and Application Ser. No. 12/414,007 (published US 2010-0250777 A1), filed on 2009 Mar. 30, entitled “Methods, Systems, and Computer Program Products for Resolving a First Source Node Identifier to a Second Source Node Identifier”.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5195181 | Bryant et al. | Mar 1993 | A |
| 5353283 | Tsuchiya | Oct 1994 | A |
| 5426639 | Follett et al. | Jun 1995 | A |
| 5452293 | Wilkinson et al. | Sep 1995 | A |
| 5504747 | Sweazey | Apr 1996 | A |
| 5649108 | Spiegel et al. | Jul 1997 | A |
| 5764624 | Endo et al. | Jun 1998 | A |
| 5845086 | Doebrich et al. | Dec 1998 | A |
| 5968124 | Takahashi et al. | Oct 1999 | A |
| 6032197 | Birdwell et al. | Feb 2000 | A |
| 6205429 | Peng | Mar 2001 | B1 |
| 6374303 | Armitage et al. | Apr 2002 | B1 |
| 6574195 | Roberts | Jun 2003 | B2 |
| 6577600 | Bare | Jun 2003 | B1 |
| 6631484 | Born | Oct 2003 | B1 |
| 6647428 | Bannai et al. | Nov 2003 | B1 |
| 6650640 | Muller et al. | Nov 2003 | B1 |
| 6675218 | Mahler et al. | Jan 2004 | B1 |
| 6728220 | Behzadi | Apr 2004 | B2 |
| 6816460 | Ahmed et al. | Nov 2004 | B1 |
| 6963570 | Agarwal | Nov 2005 | B1 |
| 6990108 | Karlsson et al. | Jan 2006 | B2 |
| 6996126 | Deml et al. | Feb 2006 | B2 |
| 7012919 | So et al. | Mar 2006 | B1 |
| 7023846 | Andersson et al. | Apr 2006 | B1 |
| 7031253 | Katukam et al. | Apr 2006 | B1 |
| 7031607 | Smith | Apr 2006 | B1 |
| 7047114 | Rogers | May 2006 | B1 |
| 7061921 | Sheth | Jun 2006 | B1 |
| 7065040 | Nagamine | Jun 2006 | B2 |
| 7068654 | Joseph et al. | Jun 2006 | B1 |
| 7072346 | Hama | Jul 2006 | B2 |
| 7082140 | Hass | Jul 2006 | B1 |
| 7088721 | Droz et al. | Aug 2006 | B1 |
| 7154416 | Savage | Dec 2006 | B1 |
| 7174387 | Shand et al. | Feb 2007 | B1 |
| 7174390 | Schulter et al. | Feb 2007 | B2 |
| 7177311 | Hussain et al. | Feb 2007 | B1 |
| 7180887 | Schwaderer et al. | Feb 2007 | B1 |
| 7181742 | Hooper | Feb 2007 | B2 |
| 7254138 | Sandstrom | Aug 2007 | B2 |
| 7260097 | Casey | Aug 2007 | B2 |
| 7269132 | Casey et al. | Sep 2007 | B1 |
| 7286479 | Bragg | Oct 2007 | B2 |
| 7286566 | Parruck et al. | Oct 2007 | B1 |
| 7315541 | Housel et al. | Jan 2008 | B1 |
| 7330440 | Bryant et al. | Feb 2008 | B1 |
| 7340535 | Alam | Mar 2008 | B1 |
| 7359377 | Kompella et al. | Apr 2008 | B1 |
| 7366865 | Lakshmanamurthy et al. | Apr 2008 | B2 |
| 7373401 | Azad | May 2008 | B1 |
| 7403542 | Thompson | Jul 2008 | B1 |
| 7420992 | Fang et al. | Sep 2008 | B1 |
| 7430210 | Havala et al. | Sep 2008 | B2 |
| 7460473 | Kodama et al. | Dec 2008 | B1 |
| 7462639 | Georges et al. | Dec 2008 | B2 |
| 7463639 | Rekhter | Dec 2008 | B1 |
| 7466661 | Previdi et al. | Dec 2008 | B1 |
| 7471669 | Sabesan et al. | Dec 2008 | B1 |
| 7529224 | Basso et al. | May 2009 | B2 |
| 7551632 | Thubert et al. | Jun 2009 | B2 |
| 7564803 | Minei et al. | Jul 2009 | B1 |
| 7577143 | Kompella | Aug 2009 | B1 |
| 7602778 | Guichard et al. | Oct 2009 | B2 |
| 7610330 | Quinn et al. | Oct 2009 | B1 |
| 7619982 | Blair et al. | Nov 2009 | B2 |
| 7636299 | Asa et al. | Dec 2009 | B2 |
| 7660892 | Choong et al. | Feb 2010 | B2 |
| 7673072 | Boucher et al. | Mar 2010 | B2 |
| 7675861 | Metzger et al. | Mar 2010 | B2 |
| 7706306 | Bardalai et al. | Apr 2010 | B2 |
| 7773630 | Huang et al. | Aug 2010 | B2 |
| 7782834 | Chitrapu | Aug 2010 | B2 |
| 7787361 | Rahman et al. | Aug 2010 | B2 |
| 7813356 | Roberts | Oct 2010 | B2 |
| 7817667 | Frederiksen et al. | Oct 2010 | B2 |
| 7835393 | Ren et al. | Nov 2010 | B2 |
| 7885259 | Filsfils | Feb 2011 | B2 |
| 7885294 | Patel et al. | Feb 2011 | B2 |
| 7894352 | Kompella et al. | Feb 2011 | B2 |
| 7894458 | Jiang et al. | Feb 2011 | B2 |
| 7933272 | Morris | Apr 2011 | B2 |
| 7940695 | Bahadur et al. | May 2011 | B1 |
| 7944853 | Eglin et al. | May 2011 | B2 |
| 7970931 | Ventakaramaiah et al. | Jun 2011 | B2 |
| 7983174 | Monaghan et al. | Jul 2011 | B1 |
| 8000267 | Solis et al. | Aug 2011 | B2 |
| 8004967 | Wang | Aug 2011 | B2 |
| 8028298 | Moore | Sep 2011 | B2 |
| 8064441 | Wijnands et al. | Nov 2011 | B2 |
| 8065439 | Johnson et al. | Nov 2011 | B1 |
| 8068417 | Roberts | Nov 2011 | B1 |
| 8073968 | Shah et al. | Dec 2011 | B1 |
| 8248920 | Tallet | Aug 2012 | B2 |
| 8248969 | Yan | Aug 2012 | B2 |
| 8254272 | Vasseur | Aug 2012 | B1 |
| 8259585 | P et al. | Sep 2012 | B1 |
| 8275313 | Myers et al. | Sep 2012 | B1 |
| 8301738 | Alex | Oct 2012 | B1 |
| 8310957 | Rekhter | Nov 2012 | B1 |
| 8339973 | Pichumani et al. | Dec 2012 | B1 |
| 8380846 | Abu-Ghazaleh et al. | Feb 2013 | B1 |
| 8422514 | Kothari et al. | Apr 2013 | B1 |
| 8456987 | Valluri et al. | Jun 2013 | B1 |
| 8509056 | Arya et al. | Aug 2013 | B1 |
| 8537840 | Raszuk et al. | Sep 2013 | B1 |
| 8542706 | Wang et al. | Sep 2013 | B2 |
| 8611335 | Wu et al. | Dec 2013 | B1 |
| 8619817 | Everson et al. | Dec 2013 | B1 |
| 8630167 | Smith | Jan 2014 | B2 |
| 8631483 | Soni et al. | Jan 2014 | B2 |
| 8675488 | Sidebottom et al. | Mar 2014 | B1 |
| 8693341 | Rajamanickam et al. | Apr 2014 | B2 |
| 8705533 | Venkatraman et al. | Apr 2014 | B1 |
| 8711883 | Kang et al. | Apr 2014 | B2 |
| 8724627 | Filsfils et al. | May 2014 | B2 |
| 8743679 | Gerstel et al. | Jun 2014 | B2 |
| 8751686 | Filsfils et al. | Jun 2014 | B2 |
| 8762532 | Kohlenz et al. | Jun 2014 | B2 |
| 8792384 | Banerjee et al. | Jul 2014 | B2 |
| 8798047 | Wadekar et al. | Aug 2014 | B1 |
| 8813220 | Knapp et al. | Aug 2014 | B2 |
| 8825900 | Gross et al. | Sep 2014 | B1 |
| 8831025 | Finney et al. | Sep 2014 | B2 |
| 8838705 | Zwaal et al. | Sep 2014 | B2 |
| 8867363 | Mohapatra et al. | Oct 2014 | B2 |
| 8873409 | Filsfils et al. | Oct 2014 | B2 |
| 8891532 | Smith et al. | Nov 2014 | B1 |
| 8892772 | Filsfils et al. | Nov 2014 | B1 |
| 8908517 | Filsfils et al. | Dec 2014 | B2 |
| 8913613 | Srinivasan et al. | Dec 2014 | B2 |
| 8948179 | Zhao et al. | Feb 2015 | B2 |
| 8953590 | Aggarwal et al. | Feb 2015 | B1 |
| 8982710 | Meilik et al. | Mar 2015 | B2 |
| 9014049 | Filsfils et al. | Apr 2015 | B2 |
| 9015299 | Shah | Apr 2015 | B1 |
| 9030934 | Shah et al. | May 2015 | B2 |
| 9036463 | Bashandy et al. | May 2015 | B2 |
| 9036474 | Dibirdi et al. | May 2015 | B2 |
| 9049233 | Frost et al. | Jun 2015 | B2 |
| 9065750 | Vasseur et al. | Jun 2015 | B2 |
| 9094335 | Subramanian et al. | Jul 2015 | B2 |
| 9094337 | Bragg et al. | Jul 2015 | B2 |
| 9112734 | Edwards et al. | Aug 2015 | B2 |
| 9118572 | Sajassi et al. | Aug 2015 | B2 |
| 9124652 | Jain et al. | Sep 2015 | B1 |
| 9143395 | Bashandy et al. | Sep 2015 | B2 |
| 9178796 | Previdi et al. | Nov 2015 | B2 |
| 9178805 | Goel | Nov 2015 | B2 |
| 9185022 | Vasseur et al. | Nov 2015 | B2 |
| 9197508 | Vasseur et al. | Nov 2015 | B2 |
| 9231726 | Lee et al. | Jan 2016 | B2 |
| 9253041 | Previdi et al. | Feb 2016 | B2 |
| 9258174 | Gerstel et al. | Feb 2016 | B1 |
| 9282031 | Liu et al. | Mar 2016 | B2 |
| 9294416 | Ceccarelli et al. | Mar 2016 | B2 |
| 9300584 | Filsfils et al. | Mar 2016 | B1 |
| 9319312 | Filsfils et al. | Apr 2016 | B2 |
| 9369371 | Filsfils et al. | Jun 2016 | B2 |
| 9369387 | Filsfils et al. | Jun 2016 | B2 |
| 9391704 | Gerstel et al. | Jul 2016 | B2 |
| 9401858 | Francois et al. | Jul 2016 | B2 |
| 9444677 | Kumar et al. | Sep 2016 | B2 |
| 9462043 | Frost et al. | Oct 2016 | B2 |
| 9479403 | Filsfils et al. | Oct 2016 | B2 |
| 9491686 | Bosch et al. | Nov 2016 | B2 |
| 9503363 | Sivabalan et al. | Nov 2016 | B2 |
| 9525619 | Filsfils et al. | Dec 2016 | B2 |
| 9544232 | Srinivasan et al. | Jan 2017 | B2 |
| 9548959 | Boutros et al. | Jan 2017 | B2 |
| 9559954 | Filsfils et al. | Jan 2017 | B2 |
| 9565160 | Previdi et al. | Feb 2017 | B2 |
| 9571349 | Previdi et al. | Feb 2017 | B2 |
| 9590850 | Filsfils et al. | Mar 2017 | B2 |
| 9634867 | Lee et al. | Apr 2017 | B2 |
| 9634924 | Filsfils et al. | Apr 2017 | B2 |
| 9634929 | Boutros et al. | Apr 2017 | B2 |
| 9647944 | Filsfils et al. | May 2017 | B2 |
| 9660897 | Gredler | May 2017 | B1 |
| 9698910 | Filsfils et al. | Jul 2017 | B2 |
| 9705815 | Mattson et al. | Jul 2017 | B2 |
| 9749227 | Frost et al. | Aug 2017 | B2 |
| 9780909 | Wood et al. | Oct 2017 | B2 |
| 9813333 | Zhao et al. | Nov 2017 | B2 |
| 9825845 | Wang et al. | Nov 2017 | B2 |
| 9825856 | Yong et al. | Nov 2017 | B2 |
| 9832115 | Cai et al. | Nov 2017 | B2 |
| 9847939 | Patel et al. | Dec 2017 | B2 |
| 9858241 | Srinivasan et al. | Jan 2018 | B2 |
| 9912577 | Filsfils et al. | Mar 2018 | B2 |
| 9929946 | Filsfils et al. | Mar 2018 | B2 |
| 9942057 | Bryant et al. | Apr 2018 | B2 |
| 9979601 | Filsfils et al. | May 2018 | B2 |
| 9979629 | Sivabalan et al. | May 2018 | B2 |
| 10142160 | Adams et al. | Nov 2018 | B1 |
| 10212076 | Morris | Feb 2019 | B1 |
| 20010037401 | Soumiya et al. | Nov 2001 | A1 |
| 20010040895 | Templin | Nov 2001 | A1 |
| 20010052053 | Nemirovsky et al. | Dec 2001 | A1 |
| 20020057651 | Roberts | May 2002 | A1 |
| 20020057699 | Roberts | May 2002 | A1 |
| 20020080786 | Roberts | Jun 2002 | A1 |
| 20020099856 | Shitama | Jul 2002 | A1 |
| 20020101868 | Clear et al. | Aug 2002 | A1 |
| 20020103631 | Feldmann et al. | Aug 2002 | A1 |
| 20020103732 | Bundy et al. | Aug 2002 | A1 |
| 20020150094 | Cheng | Oct 2002 | A1 |
| 20020176371 | Behzadi | Nov 2002 | A1 |
| 20020191541 | Buchanan et al. | Dec 2002 | A1 |
| 20030016678 | Maeno | Jan 2003 | A1 |
| 20030026271 | Erb et al. | Feb 2003 | A1 |
| 20030039212 | Lloyd et al. | Feb 2003 | A1 |
| 20030058790 | Nagamine | Mar 2003 | A1 |
| 20030099194 | Lee et al. | May 2003 | A1 |
| 20030099203 | Rajan et al. | May 2003 | A1 |
| 20030118051 | Ooms | Jun 2003 | A1 |
| 20030126272 | Corl et al. | Jul 2003 | A1 |
| 20030133412 | Iyer et al. | Jul 2003 | A1 |
| 20030142674 | Casey | Jul 2003 | A1 |
| 20030142685 | Bare | Jul 2003 | A1 |
| 20030179742 | Ogier et al. | Sep 2003 | A1 |
| 20030231634 | Henderson et al. | Dec 2003 | A1 |
| 20040032856 | Sandstrom | Feb 2004 | A1 |
| 20040160958 | Oh | Aug 2004 | A1 |
| 20040174879 | Basso et al. | Sep 2004 | A1 |
| 20040196840 | Amrutur et al. | Oct 2004 | A1 |
| 20040196854 | Thubert et al. | Oct 2004 | A1 |
| 20040202158 | Takeno et al. | Oct 2004 | A1 |
| 20040218535 | Liong et al. | Nov 2004 | A1 |
| 20040219922 | Gage et al. | Nov 2004 | A1 |
| 20040240442 | Grimminger et al. | Dec 2004 | A1 |
| 20040249951 | Grabelsky et al. | Dec 2004 | A1 |
| 20050066017 | Bogia | Mar 2005 | A1 |
| 20050071130 | Benjamin et al. | Mar 2005 | A1 |
| 20050073958 | Atlas et al. | Apr 2005 | A1 |
| 20050105515 | Reed et al. | May 2005 | A1 |
| 20050152298 | Thubert | Jul 2005 | A1 |
| 20050174998 | Vesterinen et al. | Aug 2005 | A1 |
| 20050213513 | Ngo et al. | Sep 2005 | A1 |
| 20050232303 | Deforche et al. | Oct 2005 | A1 |
| 20050240943 | Smith et al. | Oct 2005 | A1 |
| 20050259586 | Hafid et al. | Nov 2005 | A1 |
| 20050259655 | Cuervo et al. | Nov 2005 | A1 |
| 20060002304 | Ashwood-Smith | Jan 2006 | A1 |
| 20060013209 | Somasundaram | Jan 2006 | A1 |
| 20060039371 | Castro et al. | Feb 2006 | A1 |
| 20060045088 | Nguyen | Mar 2006 | A1 |
| 20060056397 | Aizu et al. | Mar 2006 | A1 |
| 20060075134 | Aalto et al. | Apr 2006 | A1 |
| 20060080421 | Hu | Apr 2006 | A1 |
| 20060092940 | Ansari et al. | May 2006 | A1 |
| 20060126272 | Horio et al. | Jun 2006 | A1 |
| 20060146696 | Li et al. | Jul 2006 | A1 |
| 20060182034 | Klinker et al. | Aug 2006 | A1 |
| 20060187817 | Charzinski et al. | Aug 2006 | A1 |
| 20060215544 | Asa et al. | Sep 2006 | A1 |
| 20060239199 | Blair et al. | Oct 2006 | A1 |
| 20060239201 | Metzger et al. | Oct 2006 | A1 |
| 20060262735 | Guichard et al. | Nov 2006 | A1 |
| 20060274716 | Oswal et al. | Dec 2006 | A1 |
| 20070019647 | Roy et al. | Jan 2007 | A1 |
| 20070053342 | Sierecki et al. | Mar 2007 | A1 |
| 20070058638 | Guichard et al. | Mar 2007 | A1 |
| 20070064715 | Lloyd et al. | Mar 2007 | A1 |
| 20070112975 | Cassar | May 2007 | A1 |
| 20070133406 | Vasseur | Jun 2007 | A1 |
| 20070147363 | Oswal et al. | Jun 2007 | A1 |
| 20070171825 | Roberts et al. | Jul 2007 | A1 |
| 20070171826 | Roberts et al. | Jul 2007 | A1 |
| 20070189291 | Tian | Aug 2007 | A1 |
| 20070230362 | Bardalai et al. | Oct 2007 | A1 |
| 20070237160 | Natarajan et al. | Oct 2007 | A1 |
| 20070245034 | Retana et al. | Oct 2007 | A1 |
| 20070266148 | Ruiz | Nov 2007 | A1 |
| 20080002699 | Rajsic | Jan 2008 | A1 |
| 20080025203 | Tallet | Jan 2008 | A1 |
| 20080034116 | Li et al. | Feb 2008 | A1 |
| 20080037117 | Seki et al. | Feb 2008 | A1 |
| 20080075016 | Ashwood-Smith | Mar 2008 | A1 |
| 20080075117 | Tanaka | Mar 2008 | A1 |
| 20080084881 | Dharwadkar et al. | Apr 2008 | A1 |
| 20080101227 | Fujita et al. | May 2008 | A1 |
| 20080101239 | Goode | May 2008 | A1 |
| 20080101367 | Weinman | May 2008 | A1 |
| 20080172497 | Mohan et al. | Jul 2008 | A1 |
| 20080189393 | Wagner | Aug 2008 | A1 |
| 20080192762 | Kompella et al. | Aug 2008 | A1 |
| 20080212465 | Yan | Sep 2008 | A1 |
| 20080225864 | Aissaoui et al. | Sep 2008 | A1 |
| 20080253367 | Ould-Brahim | Oct 2008 | A1 |
| 20080259820 | White et al. | Oct 2008 | A1 |
| 20080279201 | Lu et al. | Nov 2008 | A1 |
| 20090041038 | Martini et al. | Feb 2009 | A1 |
| 20090049194 | Csaszar et al. | Feb 2009 | A1 |
| 20090067445 | Diguet et al. | Mar 2009 | A1 |
| 20090080431 | Rekhter | Mar 2009 | A1 |
| 20090135815 | Pacella | May 2009 | A1 |
| 20090141721 | Filsfils | Jun 2009 | A1 |
| 20090161576 | Morris | Jun 2009 | A1 |
| 20090175274 | Aggarwal et al. | Jul 2009 | A1 |
| 20090213858 | Dolganow et al. | Aug 2009 | A1 |
| 20090252161 | Morris | Oct 2009 | A1 |
| 20090285101 | Lu | Nov 2009 | A1 |
| 20090290486 | Wang | Nov 2009 | A1 |
| 20090296710 | Agrawal et al. | Dec 2009 | A1 |
| 20090310481 | Deng et al. | Dec 2009 | A1 |
| 20090323694 | Miki et al. | Dec 2009 | A1 |
| 20090323696 | Schwan et al. | Dec 2009 | A1 |
| 20100010975 | Morris | Jan 2010 | A1 |
| 20100010992 | Morris | Jan 2010 | A1 |
| 20100011048 | Morris | Jan 2010 | A1 |
| 20100014424 | Agrawal et al. | Jan 2010 | A1 |
| 20100027509 | Velev | Feb 2010 | A1 |
| 20100063983 | Groarke et al. | Mar 2010 | A1 |
| 20100088717 | Candelore et al. | Apr 2010 | A1 |
| 20100103937 | O'Neil | Apr 2010 | A1 |
| 20100124220 | Morris | May 2010 | A1 |
| 20100124231 | Kompella | May 2010 | A1 |
| 20100128628 | Wu et al. | May 2010 | A1 |
| 20100142401 | Morris | Jun 2010 | A1 |
| 20100142548 | Sheth | Jun 2010 | A1 |
| 20100145602 | Morris | Jun 2010 | A1 |
| 20100145963 | Morris | Jun 2010 | A1 |
| 20100146132 | Morris | Jun 2010 | A1 |
| 20100161732 | Morris | Jun 2010 | A1 |
| 20100195516 | McReynolds et al. | Aug 2010 | A1 |
| 20100202455 | Sundaram et al. | Aug 2010 | A1 |
| 20100220739 | Ishiguro | Sep 2010 | A1 |
| 20100232435 | Jabr et al. | Sep 2010 | A1 |
| 20100241742 | Douceur et al. | Sep 2010 | A1 |
| 20100250777 | Morris | Sep 2010 | A1 |
| 20100265943 | Dong et al. | Oct 2010 | A1 |
| 20100272110 | Allan et al. | Oct 2010 | A1 |
| 20100284309 | Allan et al. | Nov 2010 | A1 |
| 20100290480 | Westphal et al. | Nov 2010 | A1 |
| 20110007670 | Yan | Jan 2011 | A1 |
| 20110060844 | Allan et al. | Mar 2011 | A1 |
| 20110063986 | Denecheau et al. | Mar 2011 | A1 |
| 20110090913 | Kim et al. | Apr 2011 | A1 |
| 20110216779 | Peterson et al. | Sep 2011 | A1 |
| 20110228780 | Ashwood-Smith et al. | Sep 2011 | A1 |
| 20110261722 | Awano | Oct 2011 | A1 |
| 20110268114 | Wijnands et al. | Nov 2011 | A1 |
| 20110273980 | Smith | Nov 2011 | A1 |
| 20110280123 | Wijnands et al. | Nov 2011 | A1 |
| 20110286326 | Awano | Nov 2011 | A1 |
| 20110286452 | Balus et al. | Nov 2011 | A1 |
| 20120044944 | Kotha et al. | Feb 2012 | A1 |
| 20120063526 | Xiao et al. | Mar 2012 | A1 |
| 20120069740 | Lu et al. | Mar 2012 | A1 |
| 20120069845 | Carney et al. | Mar 2012 | A1 |
| 20120075988 | Lu et al. | Mar 2012 | A1 |
| 20120076014 | Bragg | Mar 2012 | A1 |
| 20120082034 | Vasseur | Apr 2012 | A1 |
| 20120092986 | Chen | Apr 2012 | A1 |
| 20120106560 | Gumaste | May 2012 | A1 |
| 20120120808 | Nandagopal et al. | May 2012 | A1 |
| 20120120959 | Krause | May 2012 | A1 |
| 20120147768 | Johnsson et al. | Jun 2012 | A1 |
| 20120163384 | Takase et al. | Jun 2012 | A1 |
| 20120170461 | Long | Jul 2012 | A1 |
| 20120179796 | Nagaraj et al. | Jul 2012 | A1 |
| 20120213225 | Subramanian et al. | Aug 2012 | A1 |
| 20120218884 | Kini et al. | Aug 2012 | A1 |
| 20120230255 | Li | Sep 2012 | A1 |
| 20120236860 | Kompella et al. | Sep 2012 | A1 |
| 20120239799 | Wang et al. | Sep 2012 | A1 |
| 20120287818 | Corti et al. | Nov 2012 | A1 |
| 20120307629 | Vasseur et al. | Dec 2012 | A1 |
| 20130003728 | Kwong et al. | Jan 2013 | A1 |
| 20130021908 | Ceccarelli et al. | Jan 2013 | A1 |
| 20130051237 | Ong | Feb 2013 | A1 |
| 20130058345 | Kano | Mar 2013 | A1 |
| 20130077476 | Enyedi et al. | Mar 2013 | A1 |
| 20130077624 | Keesara et al. | Mar 2013 | A1 |
| 20130077625 | Khera et al. | Mar 2013 | A1 |
| 20130077626 | Keesara et al. | Mar 2013 | A1 |
| 20130114402 | Ould-Brahim et al. | May 2013 | A1 |
| 20130142052 | Burbidge et al. | Jun 2013 | A1 |
| 20130188634 | Magee | Jul 2013 | A1 |
| 20130219034 | Wang et al. | Aug 2013 | A1 |
| 20130227108 | Dunbar et al. | Aug 2013 | A1 |
| 20130232193 | Ali et al. | Sep 2013 | A1 |
| 20130250809 | Hui et al. | Sep 2013 | A1 |
| 20130258842 | Mizutani | Oct 2013 | A1 |
| 20130266012 | Dutta et al. | Oct 2013 | A1 |
| 20130266013 | Dutta et al. | Oct 2013 | A1 |
| 20130322248 | Guo | Dec 2013 | A1 |
| 20130343204 | Geib et al. | Dec 2013 | A1 |
| 20140003425 | Zhao et al. | Jan 2014 | A1 |
| 20140010083 | Hamdi et al. | Jan 2014 | A1 |
| 20140056300 | Zhao et al. | Feb 2014 | A1 |
| 20140067911 | Block et al. | Mar 2014 | A1 |
| 20140098675 | Frost et al. | Apr 2014 | A1 |
| 20140160925 | Xu et al. | Jun 2014 | A1 |
| 20140169370 | Filsfils et al. | Jun 2014 | A1 |
| 20140173078 | McCord et al. | Jun 2014 | A1 |
| 20140177637 | Duncan et al. | Jun 2014 | A1 |
| 20140177638 | Bragg et al. | Jun 2014 | A1 |
| 20140185618 | Perlman et al. | Jul 2014 | A1 |
| 20140189045 | Morris | Jul 2014 | A1 |
| 20140189081 | Morris | Jul 2014 | A1 |
| 20140189152 | Morris | Jul 2014 | A1 |
| 20140189153 | Morris | Jul 2014 | A1 |
| 20140189154 | Morris | Jul 2014 | A1 |
| 20140189155 | Morris | Jul 2014 | A1 |
| 20140189156 | Morris | Jul 2014 | A1 |
| 20140189159 | Morris | Jul 2014 | A1 |
| 20140192677 | Chew et al. | Jul 2014 | A1 |
| 20140198634 | Kumar et al. | Jul 2014 | A1 |
| 20140204946 | Li | Jul 2014 | A1 |
| 20140211794 | Frost et al. | Jul 2014 | A1 |
| 20140215087 | Zhao et al. | Jul 2014 | A1 |
| 20140226662 | Frost et al. | Aug 2014 | A1 |
| 20140233385 | Beliveau et al. | Aug 2014 | A1 |
| 20140254596 | Filsfils et al. | Sep 2014 | A1 |
| 20140269266 | Filsfils et al. | Sep 2014 | A1 |
| 20140269421 | Previdi et al. | Sep 2014 | A1 |
| 20140269422 | Filsfils et al. | Sep 2014 | A1 |
| 20140269698 | Filsfils et al. | Sep 2014 | A1 |
| 20140269699 | Filsfils et al. | Sep 2014 | A1 |
| 20140269721 | Bashandy et al. | Sep 2014 | A1 |
| 20140269725 | Filsfils et al. | Sep 2014 | A1 |
| 20140269727 | Filsfils et al. | Sep 2014 | A1 |
| 20140286195 | Fedyk | Sep 2014 | A1 |
| 20140317259 | Previdi et al. | Oct 2014 | A1 |
| 20140328207 | Agrawal et al. | Nov 2014 | A1 |
| 20140341222 | Filsfils et al. | Nov 2014 | A1 |
| 20140363160 | Gumaste et al. | Dec 2014 | A1 |
| 20140369356 | Bryant et al. | Dec 2014 | A1 |
| 20150003455 | Haddad et al. | Jan 2015 | A1 |
| 20150003458 | Li et al. | Jan 2015 | A1 |
| 20150003463 | Li et al. | Jan 2015 | A1 |
| 20150023328 | Thubert et al. | Jan 2015 | A1 |
| 20150030020 | Kini et al. | Jan 2015 | A1 |
| 20150109902 | Kumar et al. | Apr 2015 | A1 |
| 20150156035 | Foo et al. | Jun 2015 | A1 |
| 20150188804 | Ashwood-Smith | Jul 2015 | A1 |
| 20150195197 | Yong et al. | Jul 2015 | A1 |
| 20150200843 | Frost et al. | Jul 2015 | A1 |
| 20150207671 | Farkas et al. | Jul 2015 | A1 |
| 20150236959 | Cai et al. | Aug 2015 | A1 |
| 20150256456 | Previdi et al. | Sep 2015 | A1 |
| 20150263940 | Kini et al. | Sep 2015 | A1 |
| 20150271066 | Frost et al. | Sep 2015 | A1 |
| 20150271102 | Antich | Sep 2015 | A1 |
| 20150326473 | Dunbar et al. | Nov 2015 | A1 |
| 20150326675 | Kini et al. | Nov 2015 | A1 |
| 20150381406 | Francois et al. | Dec 2015 | A1 |
| 20160006614 | Zhao | Jan 2016 | A1 |
| 20160021000 | Previdi et al. | Jan 2016 | A1 |
| 20160028640 | Zhang et al. | Jan 2016 | A1 |
| 20160173366 | Saad et al. | Jun 2016 | A1 |
| 20160191372 | Zhang et al. | Jun 2016 | A1 |
| 20160254987 | Eckert et al. | Sep 2016 | A1 |
| 20160254988 | Eckert et al. | Sep 2016 | A1 |
| 20160254991 | Eckert et al. | Sep 2016 | A1 |
| 20160352629 | Wang et al. | Dec 2016 | A1 |
| 20160352654 | Filsfils et al. | Dec 2016 | A1 |
| 20160373317 | Ali et al. | Dec 2016 | A1 |
| 20170005877 | Papadimitriou | Jan 2017 | A1 |
| 20170019330 | Filsfils et al. | Jan 2017 | A1 |
| 20170041223 | Akashi | Feb 2017 | A1 |
| 20170048138 | Sivabalan et al. | Feb 2017 | A1 |
| 20170064717 | Filsfils et al. | Mar 2017 | A1 |
| 20170104673 | Bashandy et al. | Apr 2017 | A1 |
| 20170111261 | Francois et al. | Apr 2017 | A1 |
| 20170111277 | Previdi et al. | Apr 2017 | A1 |
| 20170230274 | Filsfils et al. | Aug 2017 | A1 |
| 20170302561 | Filsfils et al. | Oct 2017 | A1 |
| 20170302571 | Frost et al. | Oct 2017 | A1 |
| 20170324497 | Ruffini et al. | Nov 2017 | A1 |
| 20170324654 | Previdi et al. | Nov 2017 | A1 |
| 20170331672 | Fedyk et al. | Nov 2017 | A1 |
| 20170346718 | Psenak et al. | Nov 2017 | A1 |
| 20170346737 | Previdi et al. | Nov 2017 | A1 |
| 20170366453 | Previdi et al. | Dec 2017 | A1 |
| 20180034728 | Filsfils et al. | Feb 2018 | A1 |
| 20180041420 | Saad et al. | Feb 2018 | A1 |
| 20180083871 | Filsfils et al. | Mar 2018 | A1 |
| 20180109450 | Filsfils et al. | Apr 2018 | A1 |
| 20180131616 | LaBerge et al. | May 2018 | A1 |
| 20180302320 | Aranha et al. | Oct 2018 | A1 |
| Number | Date | Country |
|---|---|---|
| 1726679 | Jan 2006 | CN |
| 101247253 | Aug 2008 | CN |
| 101399688 | Apr 2009 | CN |
| 101496357 | Jul 2009 | CN |
| 101803293 | Aug 2010 | CN |
| 101841442 | Sep 2010 | CN |
| 101616466 | Dec 2010 | CN |
| 102098222 | Jun 2011 | CN |
| 102132533 | Jul 2011 | CN |
| 102299852 | Dec 2011 | CN |
| 102498694 | Jun 2012 | CN |
| 101931548 | Sep 2012 | CN |
| 102714625 | Oct 2012 | CN |
| 2974164 | Jan 2016 | EP |
| 2974176 | Jan 2016 | EP |
| 2009018728 | Feb 2009 | WO |
| 2015063618 | May 2015 | WO |
| 2015094296 | Jun 2015 | WO |
| Entry |
|---|
| U.S. Appl. No. 61/831,932. |
| U.S. Appl. No. 61/833,565. |
| U.S. Appl. No. 61/897,234. |
| U.S. Appl. No. 61/621,811. |
| U.S. Appl. No. 61/729,119. |
| Filsfils et al., “Segment Routing Architecture,” Cisco Systems, Inc., draft-filsfils-rtgwg-segment-routing-00, Jun. 28, 2013, pp. 1-28. |
| Filsfils et al., “Segment Routing Architecture,” Cisco Systems, Inc., draft-filsfils-rtgwgsegment-routing-01, Network Working Group, Internet-Draft, Oct. 21, 2013, pp. 1-28. |
| Filsfils et al., “Segment Routing Architecture,” Cisco Sytems, Inc., draft-filsfilsrtgwg-segment-routing-01, Network Working Group, Internet-Draft, Oct. 21, 2013, pp. 1-28. |
| Filsfils et al., “Segment Routing Architecture,” draft-ietf-spring-segment-routing-07, Network Working Group, Internet-Draft, Dec. 15, 2015, pp. 1-24. |
| Filsfils et al., “Segment Routing Interoperability with LDP,” Cisco Systems, Inc., draft-filsfils-springsegment-routing-ldp-interop-01; Apr. 18, 2014, pp. 1-16. |
| Filsfils et al., “Segment Routing Interoperability with LDP,” Cisco Systems, Inc., draft-filsfils-spring-segment-routingldp-interop-01.txt, Apr. 18, 2014, pp. 1-16. |
| Filsfils et al., “Segment Routing Use Cases,” draft-filsfils-rtgwg-segment-routing-use-cases-01, Network Working Group, Internet-Draft, Jul. 14, 2013, pp. 1-46. |
| Filsfils et al., “Segment Routing Use Cases,” draft-filsfils-rtgwg-segment-routing-use-cases-02, Network Working Group, Internet-Draft, Oct. 21, 2013, pp. 1-36. |
| Filsfils et al., “Segment Routing with MPLS Data Plane,” draft-ietf-spring-segment-routing-mpls-05, Network Working Group, Internet-Draft, Jul. 6, 2016, 15 pages. |
| Frost et al., “MPLS Generic Associated Channel (G-Ach) Advertisement Protocol,” Cisco Systems, Inc., draft-ietfmpls-gach-adv-00, Internet-Draft, Jan. 27, 2012, pp. 1-17. |
| Frost et al., “MPLS Generic Associated Channel (G-Ach) Advertisement Protocol,” Cisco Systems, Inc., draft-ietfmpls-gach-adv-08, Internet-Draft, Jun. 7, 2013, pp. 1-22. |
| Frost et al., “MPLS Generic Associated Channel (G-Ach) Advertisement Protocol,” Cisco Systems, Inc., Request for Comments 7212, Jun. 2014, pp. 1-23. |
| Fuller, V, et al, “Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy”, RFC 1519, pp. 1-24, Internet Engineering Task Force (IEFT), http:l/tools.ieft.org/rfc/rfc1519.txt, Jun. 1999. |
| Fuller, V. et al, “Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy” RFC 1519, Network Working Group, CIDR Address Strategy, Sep. 1993, 24 pages. |
| Geib, R., “Segment Routing Based OAM Use Case,” IETF 87, Berlin, Jul./Aug. 2013, pp. 1-3. |
| Geib, R., “Use Case for a Scalable and Topology Aware MPLS data plan moniotoring System,” Deutsch Telekom, draft-geib-spring-oam-usecase-01, Internet-Draft, Feb. 5, 2014, pp. 1-10. |
| Geib, R., “Use Case for a Scalable and Topology Aware MPLS data plan monitoring System,” Deutsch Telekom, draft-geib-spring-oam-usecase-00, Internet-Draft, Oct. 17, 2013, pp. 1-7. |
| Gerla, M., et al, “Fisheye State Routing Protocol (FSR) for Ad Hoc Netvvorks”, draft-ietf-manet-fsr-03.txt, pp. 1-17, Internet Engineering Task Force,http:f/tools.ietf.org/html/draft-ietf-manet-fsr-03.txt, Jun. 2002. |
| Glenn, R. et al, “The NULL Encryption Algorithm and Its Use With Ipsec” RFC 2410, Network Working Group, Nov. 1998, 6 pages. |
| Gredler et al., “Advertising MPLS Labels in IS-IS draftgredler-isis-label-advertisement-00,” Juniper Networks, Inc., Internet-Draft, Apr. 5, 2013, pp. 1-13. |
| Gredler et al., “Advertising MPLS LSPs in the IGP,” hannes@juniper.net, IETF87, Berlin, draft-gredler-ospf-label-advertisement-03, May 21, 2013, pp. 1-17. |
| Guilbaud, “Google-Localizing Packet Loss in a Large Complex Network,” Nicolas Guilbaud and Ross Cartlidge, Google Presentation, Feb. 5, 2013, pp. 1-43. |
| Gupta, P. et al, “Routing Lookups in Hardware at Memory Access Speeds,” Computer Systems Laboratory, Stanford University, Stanford, CA 94305-9030, 8 pages. |
| Halpern et al., “Service Function Chaining (SFC) Architecture—draft-ietf-sfc-architecture-09,” Network Workinq Group, Internet-Draft, Jun. 7, 2015, pp. 1-29. |
| Hass, Z., et al, “The Interzone Routing Protocol (IERP) for Ad Hoc Networks”, draft-ietf-manet-zone-ierp-02.txt, pp. 1-14, Internet Engineering Task Force,http://tools.ietf.org/html/draft-ietf-manet-zone-ierp-02.txt, Jul. 2002. |
| Hedrick, C, “Routing Information Protoocl”, RFC 1058, pp. 1-33, Internet Engineering Task Force, http://tools.ietf.org/rfc/rfc1058.txt, Jun. 1988. |
| Hinden et al “IPv6 Global Unicast Address Format” RFC 3587, Aug. 2003, 5 pages. |
| Hinden, R. et al, “An IPv6 Aggregatable Global Unicast Address Format” RFC 2374, Network Working Group, Jul. 1998, 12 pages. |
| Hinden, R. et al, “Internet Protocol Version 6 (IPv6) Addressing Architecture” RFC 3513, Network Working Group, Apr. 2003, 26 pages. |
| Hinden, R., et al, “Internet Protocol Version 6 (IPv6) Addressing Architecture”, RFC 3513, pp. 1-26, Internet Engineering Task Force, http://tools.ietf.org/rfc/rfc3513.txt, Apr. 2003. |
| Hinden, R., et al,, “Aggregatable Global Unicast Address Format”, RFC 2374, pp. 1-12, Internet Engineering Task Force, http:/tools.ietf.org/rfc/rfc2374, Jul. 1998. |
| Housley, R., “Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP),” Network Working Group, RFC 4309, Standards Track, Dec. 2005, 13 pages; https://tools.ietf.org/pdf/rfc4309.pdf. |
| Hu, Y., et al, “Flow State in Dynamic Source Routing Protocol for Mobile Ad Hoc Networks”, draft-ietf-manet-dsrflow-00.txt, pp. 1-30, Internet Engineering Task Force,http://tools.ietf.org/html/drafl-ietf-manet-dsrflow-OO.txt, Feb. 2001. |
| Hui. J .. et al. ““An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)””. RFC 6554. pp. 1-13. Internet Engineering Task Force. http://tools.ietf.org/rfc/rfc6554.txt. Mar. 2012. |
| Imaizumi et al., “FMEHR: An Alternative Approach to Multi-Path Forwarding on Packed Switched Networks,” Networks, 2005, pp. 196-201. |
| Jiang, M., et al, “Cluster Based Routing Protocol (CBR)”, ddrafl-ietf-manet-cbrp-spec-01.txt, pp. 1-27, Internet Engineering Task Force,http://tools.ietf.org/html/ddrafl-ietf-manet-cbrp-spec-01.txt, Aug. 1999. |
| Johnson, D., et al, “The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4”, RFC 4728, pp. 1-107, Internet Engineering Task Force, http://lools.ielf.org/rfc/rfc4728.lxl, Feb. 2007. |
| Kent et al., “Security Architecture for the Internet Protocol,” Network Working Group, RFC 4301, Standards Track, Dec. 2005, 101 pages; https://tools.ietf.org/pdf/rfc4301.pdf. |
| Kettaf, N., et al, “Admission Control enabled on demand Routing (ACOR)”, drafl-kettaf-manet-acor-03.txt pp. 1-24, Internet Engineering Task Forcer,http://tools.ietf.org/html/draft-kettaf-manet-acor-03.txt, Oct. 2007. |
| Kompella et al, “Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Enginerring (TE),” Juniper Networks, Network Working Group, Request for Comments 4206, Oct. 2005, pp. 1-14. |
| Kompella et al., “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” Juniper Networks, Inc., Network Working Group, Request for Comments 4379, Feb. 2006, pp. 1-50. |
| Kompella et al., “Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling,” Network Working Group, Request for Comments 4761, Juniper Networks, Jan. 2007, pp. 1-28. |
| Kumar et al., “Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using MPLS Dataplane,” Cisco Systems, Inc., draft-kumar-mpls-spring-lsp-ping-00, Oct. 21, 2013, pp. 1-12. |
| Kumar et al., “Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using MPLS Dataplane,” draft-ietf-mpls-spring-lsp-ping-00, Network Work Group, Internet Draft, May 10, 2016, 17 pages. |
| Kumar et al., “Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using MPLS Dataplane,” draftkumarkini-mpls-spring-lsp-ping-00, Network Work Group, Internet-Draft, Jan. 2, 2014, pp. 1-15. |
| Notice of Allowance dated Mar. 1, 2019 for U.S. Appl. No. 15/961,826. |
| Notice of Allowance dated Mar. 7, 2019 for U.S. Appl. No. 15/961,832. |
| Dffice Action dated Jan. 22, 2019 for U.S. Appl. No. 16/153,223. |
| Dffice Action dated Jan. 24, 2019 for U.S. Appl. No. 16/153,262. |
| Dffice Action dated Feb. 7, 2019 for U.S. Appl. No. 16/153,168. |
| Dffice Action dated Feb. 26, 2019 for U.S. Appl. No. 16/153,146. |
| Dffice Action dated Mar. 12, 2019 for U.S. Appl. No. 16/153,196. |
| Office Action dated Mar. 14, 2019 for U.S. Appl. No. 16/195,827. |
| Office Action dated Mar. 21, 2019 for U.S. Appl. No. 16/195,816. |
| Office Action dated Mar. 21, 2019 for U.S. Appl. No. 16/195,830. |
| Abandonment dated Jun. 24, 2019 for U.S. Appl. No. 15/961,832. |
| Advisory_Action_dated Sep. 17, 2019_for_U.S. Appl. No. 16/195,830. |
| Final Rejection dated Jun. 13, 2019 for U.S. Appl. No. 16/153,114. |
| Final Rejection dated Jun. 14, 2019 for U.S. Appl. No. 16/195,823. |
| Final Rejection dated Jun. 17, 2019 for U.S. Appl. No. 16/195,827. |
| Final Rejection dated Jul. 12, 2019 for U.S. Appl. No. 16/264,580. |
| Final Rejection dated Jul. 22, 2019 for U.S. Appl. No. 16/195,830. |
| NOA_dated Aug. 22, 2019_for_U.S. Appl. No. 16/153,262. |
| NOA_dated Aug. 26, 2019_for_U.S. Appl. No. 16/153,114. |
| Non-Final Rejection dated May 15, 2019 for U.S. Appl. No. 16/181,286. |
| Non-Final Rejection dated Jun. 10, 2019 for U.S. Appl. No. 16/296,195. |
| Non-Final Rejection dated Jun. 14, 2019 for U.S. Appl. No. 16/269,524. |
| Non-Final Rejection dated Jul. 31, 2019 for U.S. Appl. No. 16/454,040. |
| Non-Final Rejection dated Aug. 1, 2019 for U.S. Appl. No. 16/454,030. |
| Non-Final Rejection dated Aug. 1, 2019 for U.S. Appl. No. 16/454,043. |
| Non-Final_Rejection_dated Sep. 12, 2019_for_U.S. Appl. No. 16/195,823. |
| Notice of Allowance dated May 16, 2019 for U.S. Appl. No. 16/153,262. |
| Notice of Allowance dated May 17, 2019 for U.S. Appl. No. 16/153,050. |
| Notice of Allowance dated May 22, 2019 for U.S. Appl. No. 16/101,382. |
| Notice of Allowance dated May 24, 2019 for U.S. Appl. No. 16/101,387. |
| Notice of Allowance dated May 28, 2019 for U.S. Appl. No. 16/101,386. |
| Notice of Allowance dated May 28, 2019 for U.S. Appl. No. 16/195,816. |
| Notice of Allowance dated May 31, 2019 for U.S. Appl. No. 16/101,382. |
| Notice of Allowance dated Jun. 1, 2019 for U.S. Appl. No. 15/961,826. |
| Notice of Allowance dated Jun. 4, 2019 for U.S. Appl. No. 15/961,828. |
| Notice of Allowance dated Jun. 4, 2019 for U.S. Appl. No. 15/961,832. |
| Notice of Allowance dated Jun. 7, 2019 for U.S. Appl. No. 16/101,380. |
| Notice of Allowance dated Jun. 14, 2019 for U.S. Appl. No. 16/195,832. |
| Notice of Allowance dated Jun. 24, 2019 for U.S. Appl. No. 16/101,386. |
| Notice of Allowance dated Jun. 11, 2019 for U.S. Appl. No. 16/153,146. |
| Notice of Allowance dated Jun. 11, 2019 for U.S. Appl. No. 16/153,196. |
| Notice of Allowance dated Jun. 11, 2019 for U.S. Appl. No. 16/153,223. |
| Notice of Allowance dated Jul. 3, 2019 for U.S. Appl. No. 16/153,196. |
| Notice of Allowance dated Jul. 12, 2019 for U.S. Appl. No. 16/195,827. |
| Notice of Allowance dated Jul. 22, 2019 for U.S. Appl. No. 16/101,387. |
| Notice of Allowance dated Jul. 22, 2019 for U.S. Appl. No. 16/153,050. |
| Notice of Allowance dated Jul. 22, 2019 for U.S. Appl. No. 16/153,168. |
| Notice of Allowance dated Jul. 31, 2019 for U.S. Appl. No. 16/101,380. |
| Notice of Allowance dated Aug. 5, 2019 for U.S. Appl. No. 16/153,146. |
| Notice of Allowance dated Aug. 9, 2019 for U.S. Appl. No. 16/153,223. |
| Notice of Allowance dated Aug. 12, 2019 for U.S. Appl. No. 16/153,262. |
| Notice of Allowance dated Aug. 13, 2019 for U.S. Appl. No. 16/195,827. |
| Notice of Allowance dated Sep. 5, 2019 for U.S. Appl. No. 16/264,580. |
| Reconsideration After Non-Final Rejection dated Apr. 9, 2019 for U.S. Appl. No. 16/153,114. |
| Reconsideration After Non-Final Rejection dated May 17, 2019 for U.S. Appl. No. 16/264,580. |
| Reconsideration After Non-Final Rejection dated May 20, 2019 for U.S. Appl. No. 16/264,580. |
| Final Rejection dated Mar. 28, 2019 for U.S. Appl. No. 16/101,386. |
| Non-Final Rejection filed Apr. 17, 2019 for U.S. Appl. No. 16/195,832. |
| Non-Final Rejection dated Apr. 4, 2019 for U.S. Appl. No. 16/153,114. |
| Non-Final Rejection dated May 6, 2019 for U.S. Appl. No. 16/264,580. |
| Notice of Allowance filed Mar. 29, 2019 for U.S. Appl. No. 16/101,382. |
| Notice of Allowance filed Mar. 29, 2019 for U.S. Appl. No. 16/101,387. |
| Notice of Allowance filed Apr. 17, 2019 for U.S. Appl. No. 16/153,146. |
| Notice of Allowance filed Apr. 19, 2019 for U.S. Appl. No. 16/195,816. |
| Notice of Allowance filed Apr. 12, 2019 for U.S. Appl. No. 16/101,386. |
| Notice of Allowance dated Mar. 27, 2019 for U.S. Appl. No. 15/961,828. |
| Notice of Allowance dated Apr. 17, 2019 for U.S. Appl. No. 16/153,146. |
| Notice of Allowance dated Apr. 19, 2019 for U.S. Appl. No. 16/195,816. |
| Notice of Allowance dated Apr. 25, 2019 for U.S. Appl. No. 16/153,223. |
| Notice of Allowance dated Apr. 29, 2019 for U.S. Appl. No. 16/153,196. |
| Notice of Allowance dated Apr. 30, 2019 for U.S. Appl. No. 15/961,826. |
| Response to Final Office Action dated Apr. 30, 2019 for U.S. Appl. No. 16/153,050. |
| Abley. J .. et al. ““Deprecation of Type 0 Routing Headers in IPv6””. RFC 5095. pages 1-7. Internet Engineering Task Force. http://tools.ielf.org/rfc/rfc5095.txt. Dec. 2007. |
| Aggarwal et al., “MPLS Upstream Label Assignment and Context Specific Label Space,” Network Working Group, FRC 5331, Aug. 2008, 13 pages. |
| Akiya et al., “Seamless Bidirectional Forwarding Detection (BFD) for Segment Routing (SR),” draft-akiyabfd-seamless-sr-01, Internet Engineering Task Force, Internet-Draft, Dec. 5, 2013, 7 pages. |
| Akiya et al., “Seamless Bidirectional Forwarding Detection (BFD) for Segment Routing (SR),” draft-akiyabfd-seamless-sr-02, Internet Engineering Task Force, Internet-Draft, Jun. 7, 2014, 7 pages. |
| Akiya et al., “Seamless Bidirectional Forwarding Detection (BFD) for Segment Routing (SR),” draft-akiyabfd-seamless-sr-03, Internet Engineering Task Force, Internet-Draft, Aug. 23, 2014, 7 pages. |
| Akiya et al., “Seamless Bidirectional Forwarding Detection (BFD) for Segment Routing (SR),” draft-akiyabfd-seamless-sr-04, Internet Engineering Task Force, Internet-Draft, Feb. 23, 2015, 7 pages. |
| Akiya et al., “Seamless Bidirectional Forwarding Detection (BFD) for Segment Routing (SR),” draft-akiyabfdseamless-sr-00, Internet Engineering Task Force, Internet-Draft, Jun. 7, 2013, 7 pages. |
| Akiya, N., “Segment Routing Implications on BFD,” Sep. 9, 2013, 2 pages. |
| Alcatel-Lucent, “Segment Routing and Path Computation Element—Using Traffic Engineering to Optimize Path Placement and Efficiency in IP/MPLS Networks,” Technology White Paper, 2015, 28 pages. |
| Aldrin et al., “Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases,” draft-ietf-bfd-seamlessuse-aase-08, Network Working Group, Internet-Draft, May 6, 2016, 15 pages. |
| Almquist, P., “Type of Service in the Internet Protocol Suite”, RFC 1349, pp. 1-28, Internet Engineering Task Force, http://lools.ielf.org/rfc./rfc1349. lxl, Jul. 1992. |
| Awduche et al., “Overview and Principles of Internet Traffic Engineering,” Network Working Group, Request for Comments, 3272, May 2002, pp. 1-71. |
| Awduche et al., “Requirements for Traffic Engineering Over MPLS,” Network Working Group, Request for Comments, 2702, Sep. 1999, pp. 1-29. |
| Awduche et al., “RSVP-TE: Extensions to RSVP for LSP Tunnels,” Network Working Group, Internet-Draft, Feb. 2001, pp. 1-12. |
| Awduche et al., “RSVP-TE: Extensions to RSVP for LSP Tunnels,” Network Working Group, RFC 3209, Dec. 2001, pp. 1-61. |
| Backes et al., “Deutsche Telekom AG's Statement About IPR Related to Draft-Geig-Spring-OAM-Usecase-01,” Aug. 23, 2012, pp. 1-2. |
| Backes et al., “Deutsche Telekom AG's Statement About IPR Related to Draft-Geig-Spring-OAM-Usecase-01,” Feb. 5, 2014, pp. 1-2. |
| Baker, F. (ed), “Requirements for IP Version 4 Routers”, RFC 1812, pp. 1-175, Internet Engineering Task Force, http://tools.ietf.org/rfc/rfc1812.txt, Jun. 1995. |
| Bates et al., “Multiprotocol Extensions for BGP-4,” Network Working Group, RFC 4760, Standards Track, Jan. 2007, 47 pages; https://tools.ietf.org/pdf/rfc4760.pdf. |
| Begtasevic, F. et al. “Measurements of the Hopcount in Internet,” Delft University of Technology, Information Technology and Systems, 7 pages. |
| Bergkvist, J., et al, “Boomerang—A Simple Resource Reservation Framework for IP”, drafl-ietf-manet-cbrp-spec-01.txt, pp. 1-15, Internet Engineering Task Force.http ://tools.ietf.org/html/drafl-ietf-manet-cbrp-spec-01.txt, Nov. 2000. |
| Bryant et al., “IP Fast Reroute Using Tunnels-draft-bryant-ipfrr-tunnels-03,” Cisco Systems, Network Working Group, Internet-Draft, Nov. 16, 2007, pp. 1-30. |
| Bryant et al., “Remote LFA FRR,” Cisco Systems, draft-ietf-rtgwg-remote-lfa-04, Network Working Group, Internet-Draft, Nov. 22, 2013, pp. 1-24. |
| Chandranmenon, Girish and Varghese, George. “Trading Packet Headers for Packet Processing,” SIGCOMM, 1995. |
| Chroboczek, J., “The Babel Routing Protocol”, RFC 6126, pp. 1-45, Internet Engineering Task Force, http://tools.ietf_org/rfc/rfc6126. txt, Apr. 2011. |
| Cisco Systems, Inc., “Introduction to Intermediate System-to-Intermediate System Protocol,” published 1992-2002; pp. 1-25. |
| Clausen,T. et al {ed), “Optimized Link State Routing Protocol {OSLR)”, RFC 3626, pp. 1-75, Internet Engineering Task Force, http://tools.ietf.org/rfc/rfc3626.txt, Oct. 2003. |
| Bolton, R., et al, “OSPF for IPv6”, RFC 2740, pp. 1-80, Internet Engineering Task Force, http:fftools.ietf.org/rfc/rfc2740.txt, Dec. 1999. |
| Crabbe et al., “PCEP Extensions for MPLS-TE LSP Protection With Stateful PCE Draft-Crabbe-PCE-Stateful-PCE-Protection-00,” Network Working Group, Internet-Draft, Oct. 2012, pp. 1-12. |
| Crabbe et al., “PCEP Extensions for MPLS-TE LSP Protection With Stateful PCE Draft-Crabbe-PCE-Stateful-PCTProtection-04,” Network Working Group, Internet-Draft, May 8, 2013, pp. 1-54. |
| Crabbe et al., Stateful PCE Extensions for MPLS-TE LSPs, draft-crabbe-pce-stateful-pce-mpls-te-00, Network Working Group, Internet-Draft, Oct. 15, 2012, pp. 1-15. |
| Crabbe et al., “Stateful PCE Extensions for MPLS-TE LSPs,” draft-crabbe-pce-statement-pce-mpls-te-01, Network Norking Group, Internet-Draft, May 8, 2013, pp. 1-11. |
| Deering et al., “Internet Protocol, Version 6 (1Pv6) Specification,” Cisco, Network Working Group, Request for Comments 2460, Dec. 1998, pp. 1-39. |
| Deering, S, et al, “Internet Protocol, Version 6, (IPv6) Specification”, RFC 2460, pp. 1-39, Internet Engineering Task Force (IEFT), http://tools.iefl.org/rfc/rfc2460. txt, Dec. 1998. |
| Deering, S. (ed)., “ICMP Router Discovery Messages”, RFC 1256, pp. 1-19, Internet Engineering Task Force, http://tools. ielf. org/rfc/rfc1256. !xi, Sep. 1991. |
| Deering, S. et al, “IPv6 Scoped Address Architecture” RFC 4007, Network Working Group, Mar 2005, 24 pages. |
| Dragos Niculescu, “Survey of Active Network Research”, Retrieved on Jul. 22, 2004, Jul. 1999, pp. 1-13. |
| Eckert et al., “Traffic Engineering for Bit Index Explicit Replication BIER-TE, draft-eckert-bier-te-arch-01,” Network Working Group, Internet-Draft, Jul. 5, 2015, pp. 1-23. |
| Eckert T., “Traffic Engineering for Bit Index Explicit Replication BIER-TE, draft-eckert-bier-te-arch-00,” Network Eorking Group, Internet-Draft, Mar. 5, 2015, pp. 1-21. |
| Estrin, D. et al, “A Unified Approach to Inter-Domain Routing”, RFC 1322, pp. 1-38, Internet Engineering Task Force, http://lools.ielf.org/rfc/rfc1322.lx., May 1992. |
| Esytrin, D. et al, “Source Demand Routing: Packet Format and Forwarding Specification (Version 1 ).”, RFC 1940, pp. 1-27, Internet Engineering Task Force, http://lools.ielf.org/rfc/rfc1940.lxl, May 1996. |
| Farinacci et al., “Generic Routing Encapsulation (GRE),” Network Working Group, RFC 2784, Standards Track, Mar. 2000, 9 pages; https://tools.ietf.org/pdf/rfc2784.pdf. |
| Farrel et al., “A Path Computation Element (PCE)-Based Architecture,” Old Dog Consulting, Network Working Group, Request for Comments 4655, Aug. 2006, pp. 1-80. |
| Farrel et al., “Inter-Domain MPLS and GMPLS Traffic Enginerring—Resource Reservation Protocol-Traffic Enginerring (RSVP-TE) Extensions,” Old Dog Consulting, Newtork Working Group, Request for Comments 5151, Feb. 2008, pp. 1-25. |
| Farrel, “Path Computation Element,” Presentation, 11th Annual International Conference on Next Generation Internet and Related Technologies MPLS 2008, Oct. 19-22, 2008, 57 pages. |
| Fedyk et al., “Generalized Multiprotocol Label Switching (GMPLS) Control Ethernet Provider Backbone Traffic Engineering (PBB-TE),” Alcatel-Lucent, Internet Engineering Task Force (IETF), Request for Comments 6060, Mar. 2011, pp. 1-20. |
| U.S. Appl. No. 61/710,121. |
| U.S. Appl. No. 61/822,386. |
| U.S. Appl. No. 61/822,978. |
| U.S. Appl. No. 61/830,064. |
| Kumar et al., “OAM Requirements for Segment Routing Network,” draft-kumar-spring-sr-oam-requirement-00, Spring, Internet-Draft, Feb. 14, 2014, 6 pages. |
| Kumar et al., “OAM Requirements for Segment Routing Network,” draft-kumar-spring-sr-oam-requirement-01, Spring; Internet-Draft, Jul. 1, 2014, 6 pages. |
| Kumar et al., “OAM Requirements for Segment Routing Network,” draft-kumar-spring-sr-oam-requirement-02, Spring, Internet-Draft, Dec. 31, 2014, 6 pages. |
| Kumar et al., “OAM Requirements for Segment Routing Network,” draft-kumar-spring-sr-oam-requirement-03, Spring, Internet-Draft, Mar. 9, 2015, 6 pages. |
| Lauder, P. et al, “Hierarchical Network Routing,” Software Systems Research Group, Department of Computer Scient, University of Sydney, 13 pages, available at www.janeelix.com/piers/papers/Routing/routing.html. |
| Li et al., “IS-IS Extensions for Traffic Engineering,” Redback Networks, Inc., Network Working Group, Request for Comments 5305, Oct. 2008, 17 pages. |
| Li, T. (ed), “Recommendataion for a Routing Architecture”, RFC 6115, pp. 1-73, Internet Engineering Task Force, http:/ftools.ietf.org/rfc/rfc6115.txt, Feb. 2011. |
| Lougheed, K., et al, (ed.),“A Border Gateway Protocol 3 (BGP-3)”, RFC 1267, pp. 1-35, Internet Engineering Task Force, http://tools.ietf.org/rfc/rfc1267.txt, Oct. 1991. |
| Mahalingam et al., “Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks,” Network Working Group, RFC 7348, Aug. 2014, 22 pages; https://tools.ietf.org/pdf/rfc7348.pdf. |
| Metaswitch Networks, “PCE—An Evolutionary Approach to SDN,” Metaswitch Networks White Paper, 2010, 21 pages; http://www.metaswitch.com/sites/default/files/metaswitch-white-paper-pce-an-evolutionary-approach-to-sdn.pdf. |
| Moy, J, “OSPF Version 2”, RFC 2328, pp. 1-13, Internet Engineering Task Force, http://tools.ietf.org/rfc/rfc2328.txt, Oct. 1991. |
| Neumann, A., et al, “Better Approach to Mobile Ad-hoc Networking (BAT.MAN.)”, draft-wunderlich-openmesh-manet-routing-00.txt pp. 1-24, Internet Engineering Task Force,http://tools.ietf.org/html/drafl-wunderlich-openmesh-manet-routing-003.txt, Apr. 2008. |
| Office Action Summary in U.S. Appl. No. 13/727,662 dated Apr. 10, 2015. |
| Oran, D., (ed.), “OSI IS-IS Intrad-domain Routing Protocol”, RFC 1142, pp. 1-193, Internet Engineering Task Force, http://tools.ietf.org/rfc/rfc1142. txt, Feb. 1990. |
| Pao, D. et al, “Efficient Hardware Architecture for Fast IP Address Lookup” IEEE, Proceedings Twenty First Annual Joint Conference of the IEEE Computer and Communications Societies, Jun. 23-27, 2002, vol. 2, pp. 555-561. |
| Perkins, C. et al, “Ad hoc On-Demand Distance Vector (AODV) Routing”, RFC 3561, pp. 1-37, Internet Engineering Task Force, http://lools.ielf.org/rfc/rfc3561.lxl, Jul. 2003. |
| Pignataro et al., “Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS,” draftietf-bfd-seamless-ip-06, Internet Engineering Task Force, Internet-Draft, May 6, 2016, 8 pages. |
| Pignataro et al.,“Seamless Bidirectional Forwarding Detection (S-BFD),” draft-ietf-bfd-seamless-base-11, Internet Engineering Task Force, Internet-Draft, May 6, 2016, 21 pages. |
| Postel, J et al “Comments on the IP Source Route Option” RFC unnumbered, IETF 1987, 18 pages. |
| Postel, J. et al. “Darpa Internet Program Protocol Specification RFC 791”, Sep. 1981, prepared for DARPA by Information Sciences Institute, University of Southern California, 50 pages, IETF. |
| Postel, J; “Internet Protocol, DARPA Internet Protocol Specification”, RFC 791 ,pp. 1-45, Internet Engineering Task Force (IEFT), http://tools.iefl.org/rfc/rfc791.txt, Sep. 1981. |
| Postel, John (ed.), Editor; “Transmission Control Protocol—DARPA Internet Protocol Specification”, RFC 793, pp. 1-85, USC/Information Sciences Institute, http://tools.ietf.org/rfc/rfc793.txt, Sep. 1981. |
| Previdi et al., “IS-IS Extensions for Segment Routing,” draft-ietf-isis-segment-routing-extensions-05, IS-IS for IP Internets, Internet-Draft, Jun. 30, 2015, pp. 1-37. |
| Previdi et al., “IS-IS Extensions for Segment Routing,” draft-ietf-isis-segment-routing-extensions-06, IS-IS for IP Internets, Internet-Draft, Dec. 14, 2015, pp. 1-39. |
| Previdi et al., “Segment Routing Egress Peer Engineering BGPLS Extensions”, Network Working Group Internet-Draft, < draft-previdi-idr-bgpls-segment-routing-epe-01 >, Internet Engineering Task Force Trust, Oct. 25, 2014, 16 pages. |
| Previdi et al., “Segment Routing with IS-IS Routing Protocol, draft-previdi-filsfils-isis-segment-routing-00,” Cisco Systems, Inc., IS-IS for IP Internets, Internet-Draft, Mar. 12, 2013, pp. 1-27. |
| Previdi et al., “Segment Routing with IS-IS Routing Protocol, draft-previdi-filsfils-isis-segment-routing-02,” Cisco Systems, Inc., Internet-Draft Mar. 20, 2013, pp. 1-27. |
| Psenak et al. “OSPF Extensions for Segment Routing,” draft-ietf-ospf-segment-routing-extensions-05, Open Shortest Path First IGP, Internet-Draft, Jun. 26, 2015, pp. 1-29. |
| Quinn et al., “Network Service Header—draft-quinn-sfc-nsh-07.txt,” Network Working Group, Internet-Draft, Feb. 24, 2015, pp. 1-43. |
| Raszuk, R., “MPLS Domain Wide Labels,” NTT 13, draft-raszuk-mpls-domain-widelabels-00, MPLS Working Group, Internet-Draft, Jul. 14, 2013, pp. 1-6. |
| Rekhter et al.,“Carrying Label Information in BGP-4,” Request for Comments 3107, The Internet Society, May 2001, 8 pages. |
| Rekhter, et. al, “Application of the Border Gateway Protocol in the Internet”, RFC 1268, pp. 1-13, Internet Engineering Task Force, http://tools.ietf.org/rfc/rfc1268.txt, Oct. 1991. |
| Rekhter, Y. et al (ed), “A Border Gateway Protocol 4 {BGP-4)”, RFC 4271, pp. 1-104, Internet Engineering Task Force, http://tools.ietf.org/rfc/rfc4271.txt, Jan. 2006. |
| Roberts, Lawrence, “A Radical New Router”, IEEE Spectrum, Jul. 2009, pp. 1-6. |
| Rosen et al. “Multiprotocol Label Switching Architecture,” RFC 3031, Jan. 2001, 61 pages. |
| Rosen et al., “BGP/MPLS IP Virtual Private Networks (VPNs),” Network Working Group, RFC 4364, Standards Track, Feb. 2006, 47 pages; https://tools.ietf.org/pdf/rfc4364.pdf. |
| Rosen et al., “BGP/MPLS VPNs”, Cisco Systems, Inc., Network Working Group, Request for Comments: 2547; Mar. 1999, pp. 1-25. |
| Sivabalan et al., “PCE-Initiated Traffic Engineering Path Setup in Segment Routed Networks; draft-sivabalan-pcesegmentrouting-00,” Internet Engineering Task Force, IETF, Standard Working Draft, Internet Society (ISOC) 4, Rue Des Falaises CH-1205, Geneva, Switzerland, Jun. 2013, pp. 1-16. |
| Steenstrup, M., “Inter-Domain Policy Routing Protocol Specification: Version 1”, RFC 1479, pp. 1-108, Internet Engineering Task Force, http://tools.ietf.org/rfc/rfc1479.txt, Jul. 1993. |
| Tian et al., “Source Routed MPLS LSP Using Domain Wide Label,” draft-tian-mpls-lsp-source-route-01.txt, Redback Networks, Network Working Group, Internet Draft, Jul. 2004, pp. 1-12. |
| Vasseur et al., “A Link-Type Sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signaled with Zero Reserved Bandwidth Across a Link,” Cisco Systems, Inc., Network Working Group, Request for Comments 5330, Oct. 2008, 16 pages. |
| Vasseur et al., “Path Computation Element (PCE) Communication Protocol (PCEP) Request for Comments: 5440,” Cisco Systems, Internet Engineering Task Force, IETF, Standard, Internet Society (ISOC) 4, Rue Des Falaises CH-1205, Geneva, Switzerland, chapters 4-8, Mar. 2009, pp. 1-87. |
| Waitzman, D., et al, “Distance Vector Multicast Routing Protocol”, RFC 1075, pp. 1-24, Internet Engineering Task Force, http://tools.ietf.org/rfc/rfc1075.txt, Nov. 1988. |
| Wang et al., “Research and Implementation of a Scalable Secure Active Network Node”, Proceedings of the First International Conference on Machine Learning and Cybernetics, IEEE, Nov. 2002, pp. 111-115. |
| Wetherall et al., “The Active IP Option,” Proceedings of the 7th Workshop of ACM SIGOPS Systems Support for Worldwide Applications, Sep. 1996, pp. 33-40. |
| Wijnands et al., “Multicast Extensions for LDP,” Cisco Systems, Inc., Yuji Kamite and Hitoshi Fukuda, NTT Communications, Network Working Group; Internet Draft; Mar. 2005, pp. 1-12. |
| U.S. Appl. No. 13/927,394. |
| U.S. Appl. No. 13/944,050. |
| U.S. Appl. No. 14/029,600. |
| U.S. Appl. No. 14/047,310. |
| U.S. Appl. No. 14/096,358. |
| U.S. Appl. No. 14/155,601. |
| U.S. Appl. No. 14/205,245. |
| U.S. Appl. No. 14/210,837. |
| U.S. Appl. No. 14/211,065. |
| U.S. Appl. No. 14/211,101. |
| U.S. Appl. No. 14/211,174. |
| U.S. Appl. No. 14/211,274. |
| U.S. Appl. No. 14/212,084. |
| U.S. Appl. No. 14/212,284. |
| U.S. Appl. No. 14/244,502. |
| U.S. Appl. No. 14/279,659. |
| U.S. Appl. No. 14/292,264. |
| U.S. Appl. No. 14/315,570. |
| U.S. Appl. No. 14/319,353. |
| U.S. Appl. No. 14/334,300. |
| U.S. Appl. No. 14/449,632. |
| U.S. Appl. No. 14/527,025. |
| U.S. Appl. No. 14/637,510. |
| U.S. Appl. No. 14/659,220. |
| U.S. Appl. No. 14/717,665. |
| U.S. Appl. No. 14/825,273. |
| U.S. Appl. No. 14/851,361. |
| U.S. Appl. No. 14/874,709. |
| U.S. Appl. No. 14/996,541. |
| U.S. Appl. No. 15/048,192. |
| U.S. Appl. No. 15/054,480. |
| U.S. Appl. No. 15/132,920. |
| U.S. Appl. No. 15/146,522. |
| U.S. Appl. No. 15/188,810. |
| U.S. Appl. No. 15/216,334. |
| U.S. Appl. No. 15/227,721. |
| U.S. Appl. No. 15/234,794. |
| U.S. Appl. No. 15/244,735. |
| U.S. Appl. No. 15/271,811. |
| U.S. Appl. No. 15/345,049. |
| U.S. Appl. No. 15/426,911. |
| U.S. Appl. No. 15/637,744. |
| U.S. Appl. No. 15/639,398. |
| U.S. Appl. No. 15/677,210. |
| U.S. Appl. No. 15/691,044. |
| U.S. Appl. No. 15/826,900. |
| U.S. Appl. No. 15/827,973. |
| U.S. Appl. No. 61/776,463. |
| U.S. Appl. No. 61/791,242. |
| U.S. Appl. No. 15/266,498. |
| U.S. Appl. No. 15/165,794. |
| U.S. Appl. No. 15/347,443. |
| U.S. Appl. No. 14/814,575. |
| U.S. Appl. No. 14/862,915. |
| U.S. Appl. No. 15/280,262. |
| International Application No. PCT/US2014/018206. |
| European Application No. 15160384. |
| U.S. Appl. No. 61/824,696. |
| U.S. Appl. No. 61/829,696. |
| U.S. Appl. No. 61/842,418. |
| U.S. Appl. No. 61/892,635. |
| U.S. Appl. No. 61/895,196. |
| U.S. Appl. No. 61/948,811. |
| U.S. Appl. No. 61/993,348. |
| U.S. Appl. No. 61/763,224. |
| U.S. Appl. No. 61/779,823. |
| U.S. Appl. No. 14/020,930. |
| U.S. Appl. No. 14/020,932. |
| U.S. Appl. No. 14/020,936. |
| U.S. Appl. No. 14/047,981. |
| U.S. Appl. No. 14/070,462. |
| U.S. Appl. No. 14/078,219. |
| U.S. Appl. No. 15/098,790. |
| U.S. Appl. No. 61/869,704. |
| U.S. Appl. No. 61/889,978. |
| U.S. Appl. No. 13/760,155. |
| U.S. Appl. No. 13/863,013. |
| Number | Date | Country | |
|---|---|---|---|
| 20190149449 A1 | May 2019 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61822978 | May 2013 | US | |
| 61822386 | May 2013 | US | |
| 61897234 | Oct 2013 | US | |
| 61830064 | Jun 2013 | US | |
| 61831932 | Jun 2013 | US | |
| 61833565 | Jun 2013 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14274632 | May 2014 | US |
| Child | 16181286 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13727662 | Dec 2012 | US |
| Child | 14274632 | US | |
| Parent | 13727651 | Dec 2012 | US |
| Child | 13727662 | US | |
| Parent | 13727652 | Dec 2012 | US |
| Child | 13727651 | US | |
| Parent | 13727653 | Dec 2012 | US |
| Child | 13727652 | US | |
| Parent | 13727655 | Dec 2012 | US |
| Child | 13727653 | US | |
| Parent | 13727657 | Dec 2012 | US |
| Child | 13727655 | US | |
| Parent | 13727647 | Dec 2012 | US |
| Child | 13727657 | US | |
| Parent | 13727649 | Dec 2012 | US |
| Child | 13727647 | US |
