Internet DRAFT - draft-idr-e164e214-mpbgp

draft-idr-e164e214-mpbgp






idr                                                                S. Ge
Internet-Draft                                              China Mobile
Intended status: Informational                         December 28, 2012
Expires: July 1, 2013


                      E164/214 MPBGP announcement
                    draft-idr-e164e214-mpbgp-00.txt

Abstract

   Recently, transferring the signaling of mobile network over IP
   attracts lots of attention from people.  Telephone number based on
   E.164 or E.214 or SP is the traditional routing address for mobile
   network, but actually, E.164, E.214 and SP is not supported by MP-BGP
   protocol.

   This document presents a new way to support for routing the phone
   number based on E.164, E.214 or SP though MP-BGP, by extending the
   MP-BGP for the Phone Number Routing.  It can bring optimizing for the
   network architecture and improving efficiency.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 1, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Ge                        Expires July 1, 2013                  [Page 1]

Internet-Draft         E164/214 MPBGP announcement         December 2012


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Abbreviation . . . . . . . . . . . . . . . . .  5
     2.1.  Conventions Used in This Document  . . . . . . . . . . . .  5
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  The new method to route phone number . . . . . . . . . . . . .  5
   4.  Use cases and Requirements . . . . . . . . . . . . . . . . . .  7
     4.1.  Use case1: United Location Server (ULS)  . . . . . . . . .  7
     4.2.  Use case2: Global data centers based on MP-BGP(BICC) . . .  8
     4.3.  Use case3: Global data centers based on MP-BGP(SIP)  . . .  9
     4.4.  Use case4: ENUMDNS based on MP-BGP . . . . . . . . . . . .  9
   5.  BGP Extensions for Phone Number Routing Information  . . . . . 10
     5.1.  Phone Number Routing Information NLRI  . . . . . . . . . . 10
     5.2.  Phone Number Routing Capability Advertisement  . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  Normative Reference  . . . . . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
























Ge                        Expires July 1, 2013                  [Page 2]

Internet-Draft         E164/214 MPBGP announcement         December 2012


1.  Introduction

   Currently years, more and more service of voice is transferred over
   IP network and people also pay attention to how the signaling
   transfers over IP network.  Signaling over IP network could probably
   bring more benefits, such as higher efficiency of bandwidth, lower
   cost, easy deploying and maintaining.

   Traditionally, the mobile network is linked directly though switch,
   addressing by telephone number and configuring manual route tables
   statically.  It may control the network much easier, however there
   could be much more work to update configuration of the routing tables
   when the network grows bigger and bigger.  The IP network is linked
   directly by routers, IP addressing and automatically updating the
   routing tables itself.  So there may need less manual work to update
   the routing tables.

   After combination of IP network and mobile network, phone number
   addressing is still used in mobile network.  Switches are
   communicating among each other though routers,using IP addresses and
   not connecting to other switch directly any more.

   According to figure 1 below, we can find some problems:

   1) Redundant procedure.  Switch B receives the IP packet and sends
   the IP packet to router B, during this time the packet experiences
   encapsulation, acquiring the phone number though analyzing BICC and
   many other protocols, checking the routing tables and at last
   capsulation.  Switch D repeats the same procedure.  It is unnecessary
   for switch B and D to process the packets.

   2) There exists a shortest path between router A and router E, but
   the shortest path cannot be guaranteed when the switch involved.

   3) It will acquire much more manual work to update the configuration
   of switch B and D when the network grows bigger and bigger.















Ge                        Expires July 1, 2013                  [Page 3]

Internet-Draft         E164/214 MPBGP announcement         December 2012


               +--------+----+   +--------+----+   +--------+----+
               |   NS   | ER |   |   NS   | ER |   |   NS   | ER |
               +--------+----+   +--------+----+   +--------+----+
               |1390123 | B  |   |1390123 | D  |   |1390123 | E  |
               +--------+----+   +--------+----+   +--------+----+
               | ...    | .. |   |  ...   | .. |   |   ...  | .. |
               +--------+----+   +--------+----+   +--------+----+

                calling...                             receiver..
                    +---+       +---            +---+    +---+
               ---->+ A'|       | B'            | D'|    | E'+--->
                    +-+-+       +-+-   +---+    +-+-+    +-+-+
                     /           /     | C'|       \         \
                    /           /      +-+-+        \         \
                +--++       +--++        |          ++--+    ++--+
                | A +-------+ B +--------+----------+ D +----+ E |
                +---+       +---+        |          +---+    +---+
               +--------+----+   .       |       .-'
               |IP addr | NH |    `-.  +-+-+  .-'  +--------+----+
               +--------+----+       `-. C .-'     |IP addr | NH |
               |10.0.0.0| B  |         +---+       +--------+----+
               +--------+----+  +--------+----+    |10.0.0.0| E  |
               |switchB'| B' |  |IP addr | NH |    +--------+----+
               +--------+----+  +--------+----+    |switchE'| E' |
                                |10.0.0.0| D  |    +--------+----+
                                +--------+----+
                                |switchD'| D' |
                                +--------+----+


    Figure 1: the routing procedure of mobile network combined with IP
                                  network

   NS: Number Segment

   ER: Egress Router

   NH: Next Hop

   IP addr: IP address

   A/B/C/D: Router A/B/C/D

   A'/B'/C'/D': switcher A'/B'/C'/D'

   BGP (Border Gateway Protocol) was defined in RFC4271, which manages
   the routing information based on IPv4 protocol and has not support
   for IPv6, IPX, L3VPN and other network layer protocols well when



Ge                        Expires July 1, 2013                  [Page 4]

Internet-Draft         E164/214 MPBGP announcement         December 2012


   crossing different ASs (Autonomous System).  MP-BGP (multiprotocol
   Extensions for BGP-4) was defined in RFC4760, which supports many
   network layer protocols such as IPv6, IPX, etc.  However, it is not
   supported to route E.164, E.214 and SP number information by MP-BGP.

   There are two attributes defined in MP-BGP protocol, which are
   MP_REACH_NLRI and MP_UNREACH_NLRI, both of them contain Address
   Family Identifier (AFI) used for identifying the network layer
   protocol and Subsequent Address Family Identifier (SAFI) carried the
   supplement to AFI.

   1) MP_REACH_NLRI (Multiprotocol Reachable NLRI) is used to carry the
   reachable destinations information and the next hop information used
   for forwarding to these destinations.

   2) MP_UNREACH_NLRI (Multiprotocol Unreachable NLRI) is used to carry
   the set of unreachable destinations.


2.  Terminology and Abbreviation

2.1.  Conventions Used in This Document

   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 [RFC2119].

2.2.  Terminology

   SP numbers

   Service Provider number, these numbers allocated by operators are
   used to identify the sevice providers, such as youtube, facebook etc.


3.  The new method to route phone number

   Comparing to the method shown in Figure 1, there is new method to
   route phone number though MP-BGP.  The procedure is shown in Figure
   2.

   1) According to the figure below, switch B, C and D are not involved
   in the signaling procedure, so that it can save bandwidth and
   simplifying the network architecture.

   2) The egress address matched with 1390123 in switch A is substituted
   for the IP address of switch E.




Ge                        Expires July 1, 2013                  [Page 5]

Internet-Draft         E164/214 MPBGP announcement         December 2012


   3) Considering the changes of mapping relationship between phone
   number and IP address, the phone number routing table is
   automatically learning itself just like IP routing tables.

   4) It is required for the MP-BGP protocol to support large number of
   phone number routing information and should not impact the IP
   addresses.  Additionally, the MP-BGP is mature and widespread use.

   5) By configuring the parameters of NLRI, the E.164, E.214 and SP
   routing information can be supported to transfer though MP-BGP.

                +--------+----+
                |   NS   | ER |
                +--------+----+         +----------------------+
                |1390123 | B  |_________| change  to the IP    |
                +--------+----+         |address of switch E'  |
                | ...    | .. |         +----------------------+
                +--------+----+

                 calling...                           receiver..
                     +---+                             +---+
                -----+ A'|                             | E'+------
                     +-+-+                             +-+-+
                      /                                    \
                     /                                      \
                 +--++       +---+                +---+    ++--+
                 | A +-------+ B +--------+-------+ D +----+ E |
                 +---+       +---+.       |       +---+    +---+
                +--------+----+    `.     |       .-'
                |IP addr | NH |      ;  +-+-+  .-' +--------+----+
                +--------+----+       `-. C .-'    |IP addr | NH |
                |10.0.0.0| B  |         +---+      +--------+----+
                +--------+----+  +--------+----+   |10.0.0.0| E  |
                |switchB'| B' |  |IP addr | NH |   +--------+----+
                +--------+----+  +--------+----+   |switchE'| E' |
                                 |10.0.0.0| D  |   +--------+----+
                                 +--------+----+
                                 |switchD'| D' |
                                 +--------+----+

      Figure 2: the new routing procedure without switcher B, C and D
                                 involved

   NS: Number Segment

   ER: Egress Router

   NH: Next Hop



Ge                        Expires July 1, 2013                  [Page 6]

Internet-Draft         E164/214 MPBGP announcement         December 2012


   IP addr: IP address

   A/B/C/D: Router A/B/C/D

   A'/B'/C'/D': switcher A'/B'/C'/D'


4.  Use cases and Requirements

4.1.  Use case1: United Location Server (ULS)

   The new solution based on United Location Server (ULS) integrates the
   distributed devices CMN, IPSTP and ENUMDNS into one device and then,
   chooses one ULS for global data center, other ULSs learn themselves
   automatically.  It is required to update the CMN to support IPSTP,
   ENUMDNA and MP-BGP so that ULSs and MP-BGP can communicate with each
   other.

              Province A                               Province B
           +---------------+                      +---------------+
           |        +---+  |                      |  +---+        |
           |+-----+ |MSS+--+--+------+  +------+--+--+MSS| +-----+|
           ||     | +---+  |  |      |  |      |  |  +---+ |     ||
           ||MISC +--------+--+ ULS  +--+ ULS  +--+--------+MISC ||
           ||/WAP | +---+  |  |      |  |      |  |  +---+ |/WAP ||
           |+-----+ |HLR+--+--+--+--++  +--+---+--+--+HLR| +-----+|
           |        +---+  |     |   \  /    |    |  +---+        |
           +---------------+     |    \/     |    +---------------+
           +---------------+     |    /\     |    +---------------+
           |        +---+  |     |   /  \    |    |  +---+        |
           |+-----+ |MSS+--+--+--+--++  +--+---+--+--+MSS| +-----+|
           ||     | +---+  |  |      |  |      |  |  +---+ |     ||
           ||MISC +--------+--+ ULS  +--+ ULS  +--+--------+MISC ||
           ||/WAP | +---+  |  |      |  |      |  |  +---+ |/WAP ||
           |+-----+ |HLR+--+--+------+  +------+--+--+HLR| +-----+|
           |        +---+  |                      |  +---+        |
           +---------------+                      +---------------+
              Province C                      Internetional Center

            Figure 3: Global data centers based on ULS scenario

   Requirements:

   1) CMN changes into ULS by updating.  ULS is required to support CMN,
   IPSTP, ENUMDNS and MP-BGP though Updating the CMN.

   2) MSS can access into ULS though CMN, and HLR accesses into ULS
   though IPSTP and data traffic accesses into ULS though ENUMDNS.



Ge                        Expires July 1, 2013                  [Page 7]

Internet-Draft         E164/214 MPBGP announcement         December 2012


   3) The ULS can transfer the routing information based on phone number
   among each other though MP-BGP.

   4) Routing information of different traffic based on phone number is
   stored in the routing table of different VPNs.

4.2.  Use case2: Global data centers based on MP-BGP(BICC)

   In this scenario, Reflect Routers are involved in the network.  One
   Reflect Router is used to server as global data center and others
   update automatically themselves.  It is not suitable to build big
   network, but suitable for small network, due to the full connections
   among the province data centers.

              Province A                               Province B
           +---------------+                      +---------------+
           |        +---+  |                      |  +---+        |
           |+-----+ |MSS+--+--+------+  +------+--+--+MSS| +-----+|
           ||     | +---+  |  |      |  |      |  |  +---+ |     ||
           ||MISC +--------+--+  RR  +--+  RR  +--+--------+MISC ||
           ||/WAP | +---+  |  |      |  |      |  |  +---+ |/WAP ||
           |+-----+ |HLR+--+--+--+--++  +--+---+--+--+HLR| +-----+|
           |        +---+  |     |   \  /    |    |  +---+        |
           +---------------+     |    \/     |    +---------------+
           +---------------+     |    /\     |    +---------------+
           |        +---+  |     |   /  \    |    |  +---+        |
           |+-----+ |MSS+--+--+--+--++  +--+---+--+--+MSS| +-----+|
           ||     | +---+  |  |      |  |      |  |  +---+ |     ||
           ||MISC +--------+--+  RR  +--+  RR  +--+--------+MISC ||
           ||/WAP | +---+  |  |      |  |      |  |  +---+ |/WAP ||
           |+-----+ |HLR+--+--+------+  +------+--+--+HLR| +-----+|
           |        +---+  |                      |  +---+        |
           +---------------+                      +---------------+
              Province C                      Internetional Center

           Figure 4: Global data centers based on BICC scenario

   Requirements:

   1) The data centers, HLR and digital network entities should support
   for MP-BGP.

   2) The data centers and HLR should have the capacity to communicate
   with MP-BGP.







Ge                        Expires July 1, 2013                  [Page 8]

Internet-Draft         E164/214 MPBGP announcement         December 2012


4.3.  Use case3: Global data centers based on MP-BGP(SIP)

   In this scenario, several Reflect Routers are involved into the
   network.  One Reflect Router is used for global data center, and
   others update automatically themselves.  The location of the data
   centers is more wildly dispersed and it can be awareness of problems
   that happens to data centers for network.  It is unnecessary to
   establish full connections among the data centers, because of the
   retransmit mechanism in SIP protocol.


              Province A                               Province B
           +---------------+                      +---------------+
           |        +---+  |                      |  +---+        |
           |+-----+ |MSS+--+--+------+  +------+--+--+MSS| +-----+|
           ||     | +---+  |  |      |  |      |  |  +---+ |     ||
           ||MISC +--------+--+  RR  +--+  RR  +--+--------+MISC ||
           ||/WAP | +---+  |  |      |  |      |  |  +---+ |/WAP ||
           |+-----+ |HLR+--+--+--+--++  +--+---+--+--+HLR| +-----+|
           |        +---+  |     |   \  /    |    |  +---+        |
           +---------------+     |    \/     |    +---------------+
           +---------------+     |    /\     |    +---------------+
           |        +---+  |     |   /  \    |    |  +---+        |
           |+-----+ |MSS+--+--+--+--++  +--+---+--+--+MSS| +-----+|
           ||     | +---+  |  |      |  |      |  |  +---+ |     ||
           ||MISC +--------+--+  RR  +--+  RR  +--+--------+MISC ||
           ||/WAP | +---+  |  |      |  |      |  |  +---+ |/WAP ||
           |+-----+ |HLR+--+--+------+  +------+--+--+HLR| +-----+|
           |        +---+  |                      |  +---+        |
           +---------------+                      +---------------+
              Province C                      Internetional Center

            Figure 5: Global data centers based on SIP scenario

   Requirements:

   1) All the data centers and HLR are needed to support for MP-BGP.

   2) All the data centers and HLR should have the capacity to
   communicate with MP-BGP.

4.4.  Use case4: ENUMDNS based on MP-BGP

   In this scenario, the new solution is probably the same as standard
   IMS solution and is suitable for the network built by ENUMDNS.  There
   are many ENUMDNS used for global data center, however, it only need
   one ENUMDNS to be the global data center and others update
   automatically themselves.



Ge                        Expires July 1, 2013                  [Page 9]

Internet-Draft         E164/214 MPBGP announcement         December 2012


              Province A                               Province B
           +---------------+                      +---------------+
           |        +---+  |                      |  +---+        |
           |+-----+ |MSS+--+--+------+  +------+--+--+MSS| +-----+|
           ||     | +---+  |  |      |  |      |  |  +---+ |     ||
           ||MISC +--------+--+ ENUM +--+ ENUM +--+--------+MISC ||
           ||/WAP | +---+  |  |  NDS |  |  DNS |  |  +---+ |/WAP ||
           |+-----+ |HLR+--+--+--+--++  +--+---+--+--+HLR| +-----+|
           |        +---+  |     |   \  /    |    |  +---+        |
           +---------------+     |    \/     |    +---------------+
           +---------------+     |    /\     |    +---------------+
           |        +---+  |     |   /  \    |    |  +---+        |
           |+-----+ |MSS+--+--+--+--++  +--+---+--+--+MSS| +-----+|
           ||     | +---+  |  |      |  |      |  |  +---+ |     ||
           ||MISC +--------+--+ ENUM +--+ ENUM +--+--------+MISC ||
           ||/WAP | +---+  |  |  DNS |  |  DNS |  |  +---+ |/WAP ||
           |+-----+ |HLR+--+--+------+  +------+--+--+HLR| +-----+|
           |        +---+  |                      |  +---+        |
           +---------------+                      +---------------+
              Province C                      Internetional Center

          Figure 6: Global data centers based on ENUMDNS scenario

   Requirements:

   1) ENUMDNS should support for MP-BGP.

   2) ENUMDNS should have the capability of communicate with MP-BGP.


5.  BGP Extensions for Phone Number Routing Information

5.1.  Phone Number Routing Information NLRI

   Phone Number Routing Information is exchanged in BGP UPDATE messages
   using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes defined for
   MP-BGP [RFC 4760].  The AFI value 8 is used, and a new SAFI value
   needs to be assigned for phone number routing information.

   "Length of Next Hop Network Address" in the MP_REACH_NLRI attribute
   indicates the length of the Next Hop Address.

   "Network Address of Next Hop" in the MP_REACH_NLRI attribute SHOULD
   be set to the IP address of the originating speaker of the Phone
   Number Routing Information.  It is an IPv4 address if the length of
   Next Hop address is 4 octets, or an IPv6 address if the length of the
   Next Hop address is 16 octets.




Ge                        Expires July 1, 2013                 [Page 10]

Internet-Draft         E164/214 MPBGP announcement         December 2012


   The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as
   one or more 2-tuples of the form ( length, prefix ).  The length
   field indicates the length (in bits) of the prefix.  The structure of
   the Prefix field is as table 3 below:

                      +-----------------------------------+
                      |      Type  (1 octet)              |
                      +-----------------------------------+
                      |      RD   (8 octets)              |
                      +-----------------------------------+
                      |  Phone number prefix (variable)   |
                      +-----------------------------------+

                    Table 1: Phone number prefix field

   Type: indicates the type of the phone number prefix:

   1: E.164 number prefix

   2: E.214 number prefix

   3: SP number prefix

   RD: Route Distinguisher, encoded as described in [RFC 4364].

   Phone number prefix: a variable length prefix of the phone number.
   The prefix is encoded in Binary-Coded Decimal (BCD) to represent a
   decimal phone number prefix.

5.2.  Phone Number Routing Capability Advertisement

   In order for two BGP speakers to exchange the Phone Number Routing
   Information, they must use a BGP Capabilities Advertisement to ensure
   that they both are capable of properly processing such an NLRI.  This
   is achieved as specified in [RFC4760], by using capability code 1
   (multiprotocol BGP) with an AFI of 8 and a SAFI of TBD.


6.  IANA Considerations

   This document defines a new NLRI called "Phone Number Routing
   Information".  A new SAFI value needs to be assigned for this new
   NLRI by the IANA.

   This document defines the Phone Number Routing Capability for BGP.
   The Capability code needs to be assigned by the IANA.





Ge                        Expires July 1, 2013                 [Page 11]

Internet-Draft         E164/214 MPBGP announcement         December 2012


7.  Security Considerations

   This extension to [RFC 4760] does not change the underlying security
   issues inherent in the existing BGP and [RFC 4760].


8.  Acknowledgments

   Thanks to my colleagues for their sincerely help and comments when
   drafting this document.


9.  Normative Reference

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3761]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform
              Resource Identifiers (URI) Dynamic Delegation Discovery
              System (DDDS) Application (ENUM)", RFC 3761, April 2004.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

   [RFC6141]  Camarillo, G., Holmberg, C., and Y. Gao, "Re-INVITE and
              Target-Refresh Request Handling in the Session Initiation
              Protocol (SIP)", RFC 6141, March 2011.


Author's Address

   Shu Ge
   China Mobile
   Financial Street No.29
   Xicheng District, Beijing  10033
   China

   Phone: +86-010-52686688-1734
   Email: geshu@chinamobile.com





Ge                        Expires July 1, 2013                 [Page 12]