A route distinguisher is an address qualifier used only within a single internet service provider's Multiprotocol Label Switching (MPLS) network. It is used to distinguish the distinct virtual private network (VPN) routes of separate customers who connect to the provider.
The route distinguisher is an 8-octet field prefixed to the customer's Internet Protocol address (IPv4). The resulting 12-octet field is a unique "VPN-IPv4" address. There is a more detailed description in RFC 4364. At the edge of an MPLS provider's network, a router which connects to a customer's network is called a Provider Edge (PE) router. Similarly, the customer's edge router at the other end of the connection is called a Customer Edge (CE) router. Within an MPLS network, a PE router needs to be configured to associate each route distinguisher with routes which lead to a particular CE router. The PE router may be configured to associate all routes leading to the same CE router with the same route distinguisher, or it may be configured to associate different routes with different route distinguishers, even if they lead to the same CE router.
The route distinguisher has only one purpose: to make IPv4 prefixes globally unique. It is not used for IP forwarding by the provider's core (non-edge) routers (within the MPLS cloud), but it is used by the edge routers to identify which VPN a packet belongs to. For example, for a PE router to be able to distinguish between the IP address 10.0.0.0 of one customer from the 10.0.0.0 of another customer, the network administrator must configure the PE to add a unique route distinguisher to each packet arriving from the CEs.
The route distinguisher (RD) is an 8-octet value consisting of two major fields, the Type Field (2 octets) and Value Field (6 octets). The type field determines how the value field should be interpreted. The three Type values, as defined in the Internet draft, are:
Type 0:
| Octet | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| Field | Type (2 octets) |
Administrator subfield AS Number (2 octets) |
Assigned number subfield Selected by Service Provider (4 octets) | |||||
The administrator field must contain an AS number (using private AS numbers is discouraged). The Assigned field contains a number assigned by the service provider.
Type 1:
| Octet | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| Field | Type (2 octets) |
Administrator subfield IPv4 address (4 octets) |
Assigned Number subfield Assigned by Service Provider (2 octets) | |||||
The administrator field must contain an IP address (using private IP address space is discouraged). The Assigned field contains a number assigned by the service provider.
Type 2:
| Octet | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| Field | Type (2 octets) |
Administrator subfield 4-octet AS Number (4 octets) |
Assigned Number subfield Assigned by Service Provider (2 octets) | |||||
The administrator field must contain a four-octet AS number (using private AS numbers is discouraged). The Assigned field contains a number assigned by the service provider.
Normally the Border Gateway Protocol (BGP) used by the provider's routers only looks at the four-octet IP address, but the BGP Multiprotocol Extensions allow BGP to view the entire 12-octet VPN-IPv4 address, and carry routes from multiple "address families". If the route distinguisher Administrator subfield and the Assigned Number subfield of a VPN-IPv4 address are both set to all zeroes, the VPN-IPv4 address is considered to have exactly the same meaning as the corresponding globally unique IPv4 address. In particular, this VPN-IPv4 address and the corresponding globally unique IPv4 address will be considered comparable by BGP. In all other cases, a VPN-IPv4 address and its corresponding globally unique IPv4 address will be considered noncomparable by BGP. A given per-site forwarding table will only have one VPN-IPv4 route for any given IPv4 address prefix. When a packet's destination address is matched against a VPN-IPv4 route, only the IPv4 part is actually matched.
References
- RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs), E. Rosen and Y. Rekhter, The Internet Society (February 2006)