Patent Abstract:
A method and Access Network Node for handling dissimilar protocols when a Host accesses a Broadband Network. The Access Network Node includes a protocol converter for interworking between the Neighbor Discovery (ND) protocol and the Dynamic Host Configuration Protocol (DHCP). When an ND Router Solicitation message is received from a Host that does not support DHCP, the converter converts the ND message to a DHCP Solicit message and forwards it to a Broadband Network Gateway (BNG) together with a port ID. When the Access Network Node receives a DHCP Reply message from the BNG destined for the same Host, the converter converts the DHCP Reply message to an ND Router Advertisement message before sending it to the Host.

Full Description:
TECHNICAL FIELD 
       [0001]    The present invention relates generally to communications networks. In particular, and not by way of limitation, the invention is directed to a method and protocol converter for handling dissimilar protocols when accessing a Broadband Network. 
       BACKGROUND 
       [0002]    The present invention is related to the Broadband Network system as described in the technical requirements document, TR-101 (from Broadband Forum). The current version of the TR-101 document focuses on IPv4 and it is currently being extended with IPv6 functionality (WT-177). 
         [0003]    A basic principle of the TR-101 is the ability for the Access Network (AN) to insert a DSL port-related identity into messages sent toward the Broadband Network in order for the Broadband Network Gateway (BNG) to identify the configuration associated with that end-user on that port. Thus when an end-user requests an IP-address, and the end-user uses IPoE (as opposed to IPoPPP), the Dynamic Host Configuration Protocol (DHCP) relay agent in the access network inserts an “option 82” (with the port identity) into the DHCP request before forwarding it upstream. This enables the BNG&#39;s DHCP server to uniquely identify the end-user/port/circuit (as also specified in RFC3046) related to the DHCP request. 
         [0004]    In IPv6, the IP address can be dynamically assigned by one of two methods: either DHCPv6 or the Neighbor Discovery (ND) protocol (as specified in RFC4861). The DHCPv6 method is handled in a manner similar to IPv4, using a DHCPv6 parameter to hold the port identification. The ND method, however, poses a problem because the current specification does not offer any parameter/attribute where the port identification can be inserted. 
         [0005]    Some, if not most, current commercially available broadband access devices do not offer a DHCPv6 client; they only support ND. An example of such a device is the popular PC operating system, Windows XP. When such a PC is connected to a broadband network via a residential gateway such as a bridged Customer Premises Equipment (CPE), the PC initiates ND signaling with an ND Router Solicitation (RS) message and is expecting to receive an IP address via an ND Router Advertisement (RA) message in return. However, the BNG cannot identify which port the request came from and cannot associate a certain policy with the IP address assignment (for example, limiting the number of simultaneously assigned addresses for that user). Therefore, the discovery process fails. The problem is not limited to PCs, but also applies to any user equipment (routing CPE or any device behind a bridged CPE) that uses ND for IPv6 address configuration. 
       SUMMARY 
       [0006]    Accordingly, there is a need for a method and protocol converter for handling dissimilar protocols when accessing a Broadband Network. 
         [0007]    In one embodiment, the present invention provides a protocol converter for interworking between the Neighbor Discovery (ND) protocol and the Dynamic Host Configuration Protocol (DHCP). In this embodiment, the access network (on the end-user side) terminates the Neighbor Discovery protocol (RS/RA) and uses DHCPv6 signaling towards the BNG. This process/arrangement is referred to herein as an ND/DHCP Interworking Function (IWF). This invention may utilize the Prefix delegation option (DHCPv6-PD RFC3633) of DHCPv6 with or without the DHCPv6 relay agent method (e.g., according to draft-ietf-dhc-dhcpv6-Idra). 
         [0008]    DHCPv6 is expected to be the preferable solution for IPv6 address assignment in the future. However, certain IPv6 devices are expected to support ND but not DHCPv6. The present invention advantageously supports user port identification for IPv6 devices that support ND, but not DHCPv6. This provides the BNG with a uniform way (DHCPv6) to handle address assignment to the end-user devices, independent of whether they use DHCPv6 or ND. Additionally, the invention reduces the number of messages that are sent to the BNG. Since the ND/DHCP conversion is performed in the access network, provisions do not have to be made by the IETF to handle ND in the BNG. 
         [0009]    Thus in one embodiment, the present invention is directed to a method of handling dissimilar protocols when a Host accesses a Broadband Network. The method includes the steps of receiving in an Access Network Node, an initial discovery request from the Host; and determining by the Node whether the initial discovery request is formatted in a protocol that allows a port identity to be conveyed to a gateway in the Broadband Network. When the initial discovery request is formatted in the protocol that allows a port identity to be conveyed to the gateway, the Node forwards the initial discovery request with the port identity to the gateway. However, when the initial discovery request is not formatted in the protocol that allows the port identity to be conveyed to the gateway, the Node converts the initial discovery request to a modified discovery request formatted in the protocol that allows the port identity to be conveyed to the gateway, and sends the modified discovery request with the port identity to the gateway. 
         [0010]    In another embodiment of the method of handling dissimilar protocols, the method includes the steps of receiving in the Access Network Node, an ND Router Solicitation request from the Host; utilizing the IWF in the Access Network Node to convert the ND Router Solicitation request to a DHCP Solicit message; and sending the DHCP Solicit message with a port identity to the BNG. The method may also include receiving in the Access Network Node, a DHCP Reply message from the BNG; utilizing the IWF in the Access Network Node to convert the DHCP Reply message to an ND Router Advertisement message; and sending the ND Router Advertisement message from the Access Network Node to the Host. 
         [0011]    In another embodiment, the present invention is directed to an Access Network Node for handling dissimilar protocols when a Host accesses a Broadband Network. The Access Network Node includes a message analyzer for determining whether an initial discovery request received from the Host is formatted in a protocol that allows a port identity to be conveyed to a gateway in the Broadband Network; and an interworking function for converting the initial discovery request to a modified discovery request formatted in the protocol that allows the port identity to be conveyed to the gateway, when the message analyzer determines that the initial discovery request is not formatted in the protocol that allows the port identity to be conveyed to the gateway. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0012]      FIGS. 1A-1B  are simplified block diagrams illustrating an exemplary Broadband Network access scenario without and with the ND/DHCP Interworking Function (IWF) of the present invention; 
           [0013]      FIG. 2  is a message flow diagram illustrating the flow of messages when accessing a Broadband Network Gateway (BNG) in an exemplary embodiment of the method of the present invention; 
           [0014]      FIG. 3  is a message flow diagram illustrating the flow of messages when accessing the BNG in another exemplary embodiment of the method of the present invention; and 
           [0015]      FIG. 4  is a simplified block diagram illustrating an access network node and ND/DHCP IWF in an exemplary embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0016]      FIGS. 1A-1B  are simplified block diagrams illustrating an exemplary Broadband Network access scenario without and with the ND/DHCP Interworking Function (IWF) of the present invention. Referring to  FIG. 1A , a scenario without the ND/DHCP IWF of the present invention is shown. IPv6 Host-1 11 is a device that supports ND, but not DHCPv6. IPv6 Host-2 12 is a device that supports DHCPv6. Access Network Nodes  13  are conventional access network nodes, which do not include the ND/DHCP IWF of the present invention. Therefore, the access network nodes merely forward messages they receive from the hosts to the BNG  14  utilizing the same protocol with which they were received. Thus, when the Host-2 12 sends a DHCPv6 request to the Access Network Node, the Access Network Node forwards the DHCPv6 request to the BNG  14 . There is no problem with this scenario since the DHCP relay agent in the Access Network Node inserts the “option 82” (with the port identity) into the DHCP request before forwarding it upstream. This enables the BNG&#39;s DHCP server to uniquely identify the end-user/port/circuit related to the DHCP request. However, when the Host-1 11 sends an ND request such as an RS message to the Access Network Node, the Access Network Node forwards the ND request to the BNG  14 . In this case, the BNG cannot identify which port the request came from and cannot associate any policies with the IP address assignment. 
         [0017]    Referring to  FIG. 1B , a scenario with the ND/DHCP IWF of the present invention is shown. IPv6 Host-1 11 is again a device that supports ND, but not DHCPv6. IPv6 Host-2 12 is a device that supports DHCPv6. Access Network Nodes  15  are modified to include the ND/DHCP IWF of the present invention. When the Host-2 12 sends a DHCPv6 request to the Access Network Node, the Access Network Node forwards the DHCPv6 request to the BNG  14  as before. However, when the Host-1 11 sends an ND request such as an RS message to the Access Network Node, the ND/DHCP IWF converts the ND request to a DHCPv6 request before sending the request to the BNG  14 . The ND/DHCP IWF inserts the “option 82” (with the port identity) into the DHCP request, thereby enabling the BNG&#39;s DHCP server to uniquely identify the end-user/port/circuit related to the DHCP request. 
         [0018]      FIG. 2  is a message flow diagram illustrating the flow of messages when accessing the BNG  14  in an exemplary embodiment of the method of the present invention. The IPv6 Host-1 11, sends a ND Router Solicitation request  21  to the Access Network Node  15 . The ND/DHCP IWF in the Access Network Node converts the ND request to a DHCP Solicit message  22  and sends it to the BNG  14 . The BNG returns a DHCP Advertise message  23 , and the Access Network Node responds with a DHCP Request message  24 . The DHCP Advertise message  23  and the DHCP Request message  24  are illustrated as dotted lines because they are not used if “Rapid Commit” is utilized. The BNG then returns a DHCP Reply message  25 . The ND/DHCP IWF in the Access Network Node converts the DHCP Reply message to a ND Router Advertisement message  26 . 
         [0019]    The DHCP sequence also results in a Lifetime indication in the DHCP Reply message  25 . The Access Network Node  15  indicates a slightly shorter Lifetime towards the Host-1 in the ND Router Advertisement message  26 .  FIG. 3  is a message flow diagram illustrating the flow of messages when accessing the BNG  14  in another exemplary embodiment of the method of the present invention. In this embodiment, the Access Network Node  15  is configured as a relay agent such as, for example, a Lightweight DHCP Relay Agent (LDRA), a fully functional DHCPv6 relay agent as specified in RFC3315, or a DHCPv6 transparent agent. Upon receiving the ND Router Solicitation request  21  from the IPv6 Host-1 11, the Access Network Node sends a Relay Forward message  27  to the BNG. The Relay Forward message is an encapsulation of a full DHCP Solicit or DHCP Request message. The BNG returns a Relay Reply message  28  to the Access Network Node. The Relay Reply message is an encapsulation of a full DHCP Advertise or DHCP Reply message. The Access Network Node then sends the ND Router Advertisement message  26  to the IPv6 Host-1. 
         [0020]      FIG. 4  is a simplified block diagram illustrating an Access Network Node  15  with an ND/DHCP IWF  35  in an exemplary embodiment of the present invention. The Access Network Node includes an ND message receiver  31  for receiving upstream ND messages such as ND Router Solicitation requests from the IPv6 Host-1 11, which is not capable of utilizing DHCP messages. An ND message transmitter  32  transmits ND messages such as ND Router Advertisement messages downstream to the IPv6 Host-1. Similarly, a DHCP message receiver  33  receives upstream DHCP messages from IPv6 Host-2 12, which is DHCP capable. A DHCP message transmitter  34  transmits downstream DHCP messages to the IPv6 Host-2. 
         [0021]    The ND message receiver  31  supplies received upstream messages to a message analyzer  36 , which determines whether a received message is an ND message or a DHCP message. If the received message is an ND message, the message is provided to an ND/DHCP converter  37 , which converts the ND message to a DHCP message and forwards it to a DHCP Relay Agent  38 . The DHCP Relay Agent may be, for example, an LDRA, a fully functional DHCPv6 relay agent as specified in RFC3315, or a DHCPv6 transparent agent. If the received message is a DHCP message, the message analyzer may provide the message directly to the DHCP Relay Agent. In either case, the DHCP Relay Agent forwards the DHCP message together with a Port ID to the BNG  14 . 
         [0022]    Downstream DHCP messages from the BNG  14  are received by the DHCP Relay Agent  38  and are provided to the message analyzer  36 . If the downstream DHCP message is destined to IPv6 Host-1 11, which is not DHCP capable, the message analyzer forwards the message to the ND/DHCP converter  37 . The ND/DHCP converter converts the DHCP message to an ND message and provides the ND message to the ND message transmitter  32  for transmission to the IPv6 Host-1. If the downstream DHCP message is destined to IPv6 Host-2 12, which is DHCP capable, the message analyzer may forward the message directly to the DHCP message transmitter  34  for transmission to the IPv6 Host-2. 
         [0023]    All of the operations of the Access Network Node  15  and the ND/DHCP IWF  35  may be controlled by a processor  39  running computer program instructions stored on a program memory  40 . 
         [0000]    The present invention also allows use of Unsolicited Router Advertisements sent downstream from the Access Network Node towards the host. Unsolicited RA&#39;s are sent periodically without being triggered by an RS. The AN may send out an Unsolicited RA based on DHCP information received previously from the BNG/DHCP. 
         [0024]    The present invention may of course, be carried out in other specific ways than those herein set forth without departing from the essential characteristics of the invention. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.

Technology Classification (CPC): 7