Cisco Technology, Inc.

Ole Troan

Pascal Thubert

Patrick Wetterwald

William Mark Townsley

Marco Molteni

Gunter Van De Velde

Wojciech Dec

Eric Michel Levy-Abegnoli

Keyur Patel

Ralph Droms

Francois Le Faucheur

Eric C Rosen

Daniel C Tappan

Hemant Singh

William Beebee

Luc Louis Revardel

Parag Kumar Jain

Pierre Pfister

Stig Ingvar Venaas

W Mark Townsley

Patrick Grossetete

In one embodiment, a decapsulating network device receives a plurality of encapsulated packet fragments of an original packet, and decapsulates them into respective decapsulated packet fragments. The decapsulating network device caches an inner header of the original packet from one of the decapsulated packet fragments, and in response to caching the inner header, and for each particular decapsulated packet fragment as it is received and decapsulated: prepends the inner header and fragmentation information to the particular decapsulated packet fragment; and forwards the particular decapsulated packet fragment with the prepended inner header and fragmentation information from the decapsulating network device toward a destination of the original packet.

Partial reassembly and fragmentation for decapsulation

One embodiment includes, inter alia, methods, apparatus, computer-storage media, mechanisms, and/or means associated with automated transitioning between different communication protocols in a network. In one embodiment, automatic transition routers are automatically discovered along with the knowledge of what non-native protocols need to be transported across a network. Communication pathways are automatically established as needed to transport these non-native protocols. One embodiment is particularly useful in transitioning a network from one protocol to another, such as from Internet Protocol version 4 to version 6.

Automated transitioning between different communication protocols in a network

A method is provided in one particular example and may include obtaining routing information for a plurality of Internet Protocol (IP) addresses in a first network that natively supports a first Internet protocol, the routing information for the plurality of IP addresses in the first network further comprising an additional IP address in the first network and an indication that the additional IP address in the first network is to be used as a tunnel endpoint within the first network for receiving data destined to any of the plurality of IP addresses in the first network; and sending data destined to any one of the plurality of IP addresses in the first network to the additional IP address in the first network.

Transitioning between communication protocols between networks

A method is provided in one example and includes receiving signaling data associated with a request for a multicast channel, the request includes an Internet protocol version 6 (IPv6) source and an IPv6 group address. The method may also include identifying an Internet protocol version 4 (IPv4) source and an IPv4 group address to be mapped to the IPv6 source and the IPv6 group address. The signaling data can be converted from a first protocol to a second protocol. The converted signaling data can be communicated to a network element. In more particular embodiments, the network element is an IP edge router configured to join the multicast channel and stream data in response to receiving the converted signaling data. The IP edge router can be configured to perform an encapsulation operation to transport IPv6 multicast packets within an IPv4 multicast channel.

System and method for providing multicast delivery in a network environment

A method is provided in one particular example and may include obtaining routing information for a natively supported Internet protocol of a first network that uses a first routing policy; identifying a route with a tunnel endpoint using the routing information, where the tunnel endpoint supports transitioning between a plurality of Internet protocols; generating tunnel information for the route; and sending the route and the tunnel information to a network element in a second network that uses a second routing policy.

Techniques for automatically identifying an edge-facing router in a network are provided. In one technique, a DHCP message is obtained at a router of a subscriber network. An options field of the DHCP message is identified. The options field of the DHCP message is analyzed to determine whether data in the options field indicates that first router is SP-facing. If it is determined that the router is an SP-facing router, then identification data that identifies the router as an SP-facing router is stored.

Automatically identifying an edge-facing router

Techniques for automatically identifying an edge-facing router in a network are provided. In one technique, data is obtained at a first router of a subscriber network. The data may be included in a DHCP message or a NDP RA message. The first router determines, based on the data, whether the first router is a service provider (SP)-facing router, which is a router that is coupled to a SP router and no other router in the subscriber network is logically between the SP-facing router and the SP router. If it is determined that the first router is an SP-facing router, then the first router stores identification data that identifies the first router as an SP-facing router. Otherwise, the first router stores identification data that identifies the first router as a non-SP-facing router.

A router is configured for dynamically applying an address prefix value, during execution of a router command, based on retrieving the address prefix value for an address prefix identifier specified in the router command. For example, the router may generate au IP address, for use in executing a router command, based on detecting an address prefix identifier specified in the router command, retrieving a prefix value for the address prefix identifier, and adding the prefix value to an address suffix specified in the router command. Hence, the address prefix identifier in the router command enables global reconfiguration and renumbering of all commands specifying the address prefix identifier, merely by changing the prefix value associated with the address prefix identifier.

Arrangement in a router for inserting address prefixes based on command line address identifiers

A source IPv6 mobile router is configured for establishing an IPv4 tunnel with destination IPv6 mobile router using a synthetic tag address, specifying a forwarding protocol, and IPv4 source and destination addresses. If an optional transport header is used (e.g, UDP port), the source port and destination port also are added to the synthetic tag address. The IPv6 packet includes a reverse routing header that enables the destination IPv6 mobile router to recover routing information for reaching the source IPv6 mobile router via the IPv4 network. Hence, all IPv4 routing information that may be needed by the destination IPv6 mobile router in sending an IPv6 reply packet back to the source IPv6 mobile router is maintained in the routing header specified in the IPv6 reply packet.

Arrangement for traversing an IPv4 network by IPv6 mobile routers

IPv6 traffic may be carried through an MPLS IPv4 network without the use of IPv6-over-IPv4 tunneling. This provides great savings in overhead, signaling, and state information storage and also allows for routing through the MPLS IPv4 network to adjust in response to changes in network state. In one embodiment, an edge node of an MPLS IPv4 network resolves a destination IPv6 network of a received IPv6 packet to an MPLS label switched path. The resolution exploits received inter-domain routing information. This information identifies the IPv4 address of an egress node that is usable as a gateway to the destination network. Within the inter-domain routing information, the IPv4 address may be encoded in IPv6 format.

IPv6 over MPLS IPv4 core

A source IPV6 mobile node is configured for forwarding an IPV6 packet via an IPV4 connection with a destination IPV6 router. The IPV4 packet includes IPV4 source and destination addresses, a UDP source port and UDP destination port, and a synthetic tag address in the IPV6 destination address field. The synthetic tag address, a valid (routable) IPV6 care of address, has an address prefix routed to the IPV6 router. The address prefix specifies a forwarding protocol, the IPV4 destination address for the IPV6 router, and a site-level aggregation identifier. An address suffix for the synthetic tag address specifies the IPV4 source address, the UDP source port and UDP destination port. Hence, the synthetic tag address enables the destination IPV6 router to send an IPV6 reply packet back to the source IPV6 mobile node via the IPV4 network.

Arrangement for traversing an IPv4 network by IPv6 mobile nodes

An IPv6 mobile node establishes an IPv4 connection with an IPv6 router having an IPv4 interface and configured as a Mobility Anchor Point (MAP) according to Hierarchical Mobile IPv6 Protocol. The MAP assigns a valid IPv6 care-of address to the IPv6 mobile node in response to receiving an IPv4 packet carrying an IPv6 packet requesting a valid care-of address. The IPv4 packet includes IPv4 source and destination addresses, a TCP/UDP source port and TCP/UDP destination port, and a synthetic tag address in the IPv6 source address field. The synthetic tag address includes a unique identifier that enables the MAP to associate the valid IPv6 care-of address with the IPv6 mobile node. Hence, the MAP forwards an IPv6 packet, carried via the IPv4 connection from the source IPv6 mobile node, onto an IPv6 network with an IPv6 source address field that specifies the assigned valid IPv6 care-of address.

Growing community of inventors

Oslo, Norway

Ole Troan