PCEP extensions for a BGPMPLS IPVPN

1
PCEP extensions for a BGP/MPLS
IP-VPN

• draft-kumaki-murai-pce-pcep-extension-l3vpn-00.txt

Kenji Kumaki ke-kumaki_at_kddilabs.jp (KDDI
RD Labs) Tomoki Murai murai_at_fnsc.co.jp
(FURUKAWA NETWORK SOLUTION CORP.)
2
Motivation

• Some service providers want to build new service
  which guarantees QoS or bandwidth from a local CE
  to a remote CE through the network.
• draft-ietf-l3vpn-e2e-rsvp-te-reqts
• A VPN customer desires their MPLS TE LSPs in the
  context of a BGP/MPLS IP-VPN.
• The PCE architecture is the most suitable to
  calculate customer MPLS TE LSPs.

3
Problem Statement

• There is a problem with the current
  specifications of PCEP.
• An Extension of PCEP is necessary.

192.168.2.1
192.168.2.1

• The VPN1 and the VPN2 establish a customer MPLS
  TE LSP between their sites.

4
Problem Statement(cont.)
192.168.2.1
?
PCReq message
192.168.2.1

• The PCE1 can identify each PCReq message from
  each incoming interface.
• The PCE1 forward the PCReq messages to PCE2.
• The PCE2 cant distinguish between the VPN1 PCReq
  messages and the VPN2 PCReq messages due to the
  same destination.
• The PCE 2 cant calculate an appropriate TE LSP
  between CEs per VPN.

5
PCEP Extensions

• The new Object-Types for VPN-IPv4 address and
  VPN-IPv6 address in END-POINTS object.
• END-POINTS Object-Types
• 1 IPv4, 2 IPv6, 3 VPN-IPv4, 4
  VPN-IPv6
• A new END-POINTS object consists of the original
  source/destination IPv4/IPv6 address and the
  Route Distinguisher(RD).

6
PCEP Extensions(cont.)

• The format of the END-POINTS object body

0 1 2
3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ----------
----------------------

Source VPN-IPv4 address
(12 bytes)

------------------------
--------

Destination VPN-IPv4 address (12 bytes)

----------------
---------------- 0
1 2 3 0
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
6 7 8 9 0 1 -------------------
-------------

Source VPN-IPv6 address (24 bytes)
//
// -----------
---------------------

Destination VPN-IPv6
address (24 bytes) //

// -----------------------
---------
7
Handling

• Ingress PE (PCE1)
• Deals with an original address in the END-POINTS
  object as a VPN-IPv4/IPv6 address.
• Puts VPN-IPv4/IPv6 address in the END-POINTS
  object and send the message to an Egress PE.
• Egress PE (PCE2)
• Identifies a VPN from the VPN-IPv4/IPv6 address
  in the END-POINTS object.

8
Open Issues

• There is a case where an ingress PE cant
  distinguish a path computation reply message.
• When an Ingress PE received a PCRep message for a
  PCReq message from an Egress PE, it cant
  identify a VPN only by a Request-ID in the RP
  object.
• In the current specification of PCEP, a PCRep
  message does not include the END-POINTS object
• option1 We need to expand an object to identify
  a VPN at an Ingress PE.
• option2 A PCRep message includes the END-POINTS
  object.

9
Next Steps

• Feedback from WG
• Please comment !
• Will work with yasukawas vpn-req draft.
• Will expand an object to identify a vpn at an
  Ingress PE.
• Thank you