idr S. Ge Internet-Draft China Mobile Intended status: Informational March 11, 2013 Expires: September 12, 2013 E164/214 MPBGP announcement draft-ge-mpbgp-e164e214-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 September 12, 2013. Copyright Notice Copyright (c) 2013 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 September 12, 2013 [Page 1] Internet-Draft E164/214 MPBGP announcement March 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Abbreviation . . . . . . . . . . . . . . . . 4 2.1. Conventions Used in This Document . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. The new method to route phone number . . . . . . . . . . . . 5 4. Use cases and Requirements . . . . . . . . . . . . . . . . . 6 4.1. Use case1: United Location Server (ULS) . . . . . . . . . 6 4.2. Use case2: Global data centers based on MP-BGP(BICC) . . 7 4.3. Use case3: Global data centers based on MP-BGP(SIP) . . . 8 4.4. Use case4: ENUMDNS based on MP-BGP . . . . . . . . . . . 9 5. BGP Extensions for Phone Number Routing Information . . . . . 9 5.1. Phone Number Routing Information NLRI . . . . . . . . . . 10 5.2. Phone Number Routing Capability Advertisement . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 9. Normative Reference . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 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. Ge Expires September 12, 2013 [Page 2] Internet-Draft E164/214 MPBGP announcement March 2013 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. +--------+----+ +--------+----+ +--------+----+ | 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 Ge Expires September 12, 2013 [Page 3] Internet-Draft E164/214 MPBGP announcement March 2013 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 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. Ge Expires September 12, 2013 [Page 4] Internet-Draft E164/214 MPBGP announcement March 2013 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. 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' | Ge Expires September 12, 2013 [Page 5] Internet-Draft E164/214 MPBGP announcement March 2013 |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 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 || Ge Expires September 12, 2013 [Page 6] Internet-Draft E164/214 MPBGP announcement March 2013 |+-----+ |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. 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| +-----+| | +---+ | | +---+ | Ge Expires September 12, 2013 [Page 7] Internet-Draft E164/214 MPBGP announcement March 2013 +---------------+ +---------------+ 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. 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 Ge Expires September 12, 2013 [Page 8] Internet-Draft E164/214 MPBGP announcement March 2013 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. 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 Ge Expires September 12, 2013 [Page 9] Internet-Draft E164/214 MPBGP announcement March 2013 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. 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 Ge Expires September 12, 2013 [Page 10] Internet-Draft E164/214 MPBGP announcement March 2013 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. 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. Ge Expires September 12, 2013 [Page 11] Internet-Draft E164/214 MPBGP announcement March 2013 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 September 12, 2013 [Page 12]