IPV6 Routing – some technical background

Topics
- IPv6 Fragmentation
- Configurable MTU
- Path MTU Discovery
- ICMP v6

QoS:
- Classification on TC and dot1p
- Remarking of dot1p
- Remarking of TC based on FC


RFCs:
- RFC 2460 Internet Protocol, Version 6 (IPv6) Specification
- RFC 2461 Neighbor Discovery for IPv6
- RFC 2462 IPv6 Stateless Address Auto configuration
- RFC 2463 Internet Control Message Protocol (ICMPv6) for the IP v6 specification
- RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
- RFC 3315 Dynamic Host Configuration Protocol for IPv6 (Relay Agent)
- RFC 3587 IPv6 Global Unicast Address Format
- RFC 4007 IPv6 Scoped Address Architecture
- RFC 4193 Unique Local IPv6 Unicast Addresses
- RFC 4291 IPv6 Addressing Architecture

L2VPN/VPLS-Martini and Kompella

Both Martini-draft and Kompella-draft addressed setting up of a Pseudowire emulation over MPLS in order to offer L2VPN services. These drafts were initial efforts to standardise L2VPN services.

Martini draft was named after a former Cisco employee Luca Martini. Martini draft uses LDP as signalling to setup L2VPN over MPLS backbone. The tradeoff of this draft was auto-discovery.

Kompella draft on the other hand uses BGP for both signalling and auto-discovery to establish fully-meshed pseudo wires (multipoint). Kompella-draft is named after author Keerti Kompella (Juniper Employee).

draft-martini and draft-kompella terms are used as labels for the two different L2VPN services methodologies (LDP Vs BGP for signaling). The actual drafts do not exist in IETF.

In dealing with multipoint-fully meshed topologies in edge routers, draft-martini suffered auto-discovery, to overcome aut0-discovery, it suffered configuration overhead. draft-Kompella claimed to be better scalable because of suto-discovery but with complex signalling whereas draft-martini leverages simplicity.

Martini draft was standardized under RFC 4096 . however it has since been superseded by the Pseudowire Emulation Edge to Edge (PWE3) Working Group specifications described in RFC 4447 and related documents. On the other hand draft-kompella is obsolete and was not standardized.

RFC 4664 - Framework for Layer 2 Virtual Private Networks (L2VPN), it describes the framework for L2VPNs (VPWS, VPLS and IPLS). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs. Requirements for L2VPNs can be found in RFC 4665 – Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks.

All this was consolidated, and the L2VPN Working Group produced two separate documents, RFC 4761 and RFC 4762, both offered VPLS but using different signaling protocols:

Kireeti Kompella and Yakov Rekhter published “Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Signaling” RFC 4761 in January 2007.

Marc Lasserre and Vach Kompella published “Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling” RFC 4762 in January 2007.

L2VPN services for many vendors uses RFC 4762 -Martini ( with LDP) as a standard for example Alcatel 7450’s uses RFC 4762 as the standard

Taken From ciscotips.wordpress.com

Why Should I Care About IP Multicast?

Many applications used in modern networks require information (voice, video, or data) to be sent to multiple end stations. When only a few end stations are targeted, sending multiple copies of the same information through the network (unicast) causes no ill effects. However, as the number of targeted end stations increases, the harmful effects of duplicate packets become dramatic. Deploying applications such as streaming video, financial market data, and IP telephony-based Music On Hold without enabling network devices for multicast support can cause severe degradation to a network’s performance.

What Problems Need to Be Solved?

Multicasting requires methods to efficiently deploy and scale distributed group applications across the network. This is accomplished by using protocols that reduce the network load associated with sending the same data to multiple receivers and that alleviate the high host/router processing requirements for serving individual connections.

Internet Group Management 

Protocol (IGMP)

IGMP is a protocol that allows end stations to join what is known as a multicast group. Joining a multicast group can be thought of as like subscribing to a session or service where multicast is used. IGMP relies on Class D IP addresses to create multicast groups.When a multicast session begins, the host sends an IGMP message throughout the network to discover which end stations have joined the group. The host then sends traffic to all members of that multicast group. Routers “listen” to IGMP traffic and periodically send out queries to discover which groups are active or inactive on particular LANs. Routers communicate with each other using one or more protocols to build multicast routes for each group.

Multicast Distribution Trees

Multicast-capable routers create distribution trees that control the path that IP multicast traffic takes through the network to deliver traffic to all receivers. The two basic types of multicast distribution trees are source trees and shared trees. With source trees (also known as shortest-path trees), each source sends its data to each receiver using the most efficient path, as shown in the preceding figure. Source trees are optimized for latency but have higher memory requirements, because routers must keep track of all sources. With shared trees, shown in the following figure, the multicast data is sent to a common point in the network (known as the rendezvous point) before being sent to each receiver. In the figure, Router D serves as the rendezvous point, and all multicast data is routed through it. Shared trees require less memory in routers than source trees but may not always use the optimal path, which can resulting packet delivery latency

Layer 2 Multicast

A Layer 2 switch forwards all multicast traffic, which reduces network efficiency. Two methods, Cisco Group Management Protocol (CGMP) and IGMP snooping, were developed to mitigate this inefficient switch behavior. Cisco Group Management Protocol (CGMP) CGMP allowsCisco Catalyst switches to make Layer 2 forwarding decisions based on IGMP information. When configured on switches and routers, CGMP ensures that IP multicast traffic is delivered only to ports that are attached to interested receivers, or multicast routers. With CGMP running, any router receiving a multicast join message via a switch replies to the switch with a CGMP join message. This message allows Layer 2forwarding decisions to be made. IGMP Snooping IGMP snooping improves efficiency by enabling a Layer 2 switch to view Layer 3 information (IGMP) used to populate the unicast routing table. PIM uses this unicast routing information to perform the multicast forwarding function. Although PIM is called a multicast routing protocol, it actually uses the unicast routing table to perform the RPF check function instead of building a completely independent multicast routing table. It includes two different modes of behavior for dense and sparse traffic environments—dense mode and sparse mode:

• In PIM dense mode, the multicast router floods traffic messages out all ports (referred to as a “push” model). If a router has no hosts or downstream neighbors that are members of the group, a prune message is sent, telling the router not to flood message on a particular interface. Dense mode only uses source trees. Because of the flood and prune behavior, dense mode is not recommended.
• PIM sparse mode uses what is known as an “explicit join” model. In this model, traffic is only sent to hosts that explicitly ask to receive it. This is accomplished by sending a join message to the rendezvous point. An Anycast Rendezvous Point (RP) provides load balancing, redundancy, and fault tolerance by assigning the same IP address to multiple RPs within a PIM sparse mode network multicast domain. join/leave messages) sent between hosts and routers. When an IGMP host report is sent through a switch, the switch adds the host’s port number to the associated multicast table entry. When the switch hears the IGMP leave group message from a host, the switch removes the host’s table entry. IGMP requires a switch to examine all multicast packets and therefore should be implemented only on high-end switches. Multicast Forwarding In unicast routing, traffic is routed from the source to the destination host. The router scans its routing table for the destination address and then forwards a single copy of the unicast packet out the correct interface. In multicast forwarding, the source sends traffic to several hosts, represented by a multicast group address. The multicast router must determine which direction is the upstream direction (toward the source) and which one is the downstream direction (toward the hosts). When more than one downstream path exists, the best ones (toward the group address) are chosen. These paths may or may not be the same path that would be chosen for a unicast packet. This is called Reverse Path Forwarding (RPF). RPF is used to create loop-free distribution trees.

Taken From CiscoPress