(19)
(11)EP 3 308 508 B1

(12)EUROPEAN PATENT SPECIFICATION

(45)Mention of the grant of the patent:
29.07.2020 Bulletin 2020/31

(21)Application number: 16729398.4

(22)Date of filing:  26.05.2016
(51)International Patent Classification (IPC): 
H04L 12/24(2006.01)
H04L 29/06(2006.01)
H04L 12/725(2013.01)
H04L 29/08(2006.01)
(86)International application number:
PCT/SE2016/050488
(87)International publication number:
WO 2016/204673 (22.12.2016 Gazette  2016/51)

(54)

METHODS AND NETWORK NODES FOR SCALABLE MAPPING OF TAGS TO SERVICE FUNCTION CHAIN ENCAPSULATION HEADERS

VERFAHREN UND NETZWERKKNOTEN ZUR SKALIERBAREN ABBILDUNG VON ETIKETTEN AUF DIENSTFUNKTIONSKETTENVERKAPSELUNGSHEADER

PROCÉDÉS ET NOEUDS DE RÉSEAU POUR LE MAPPAGE EXTENSIBLE D'ÉTIQUETTES À DES EN-TÊTES D'ENCAPSULATION DE CHAÎNE DE FONCTIONS DE SERVICE


(84)Designated Contracting States:
AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

(30)Priority: 15.06.2015 US 201562175925 P

(43)Date of publication of application:
18.04.2018 Bulletin 2018/16

(73)Proprietor: Telefonaktiebolaget LM Ericsson (publ)
164 83 Stockholm (SE)

(72)Inventors:
  • ROELAND, Dinand
    192 77 Sollentuna (SE)
  • CURESCU, Calin
    165 75 Hässelby (SE)
  • MONTEIRO SOARES, Joao
    169 74 Solna (SE)

(74)Representative: Zacco Sweden AB 
Valhallavägen 117 Box 5581
114 85 Stockholm
114 85 Stockholm (SE)


(56)References cited: : 
US-A1- 2014 334 488
US-A1- 2014 362 857
  
  • HAEFFNER VODAFONE J NAPPER CISCO SYSTEMS M STIEMERLING D LOPEZ TELEFONICA I+D J UTTARO AT&T W: "Service Function Chaining Use Cases in Mobile Networks; draft-ietf-sfc-use-case-mobility-03.txt", SERVICE FUNCTION CHAINING USE CASES IN MOBILE NETWORKS; DRAFT-IETF-SFC-USE-CASE-MOBILITY-03.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 13 January 2015 (2015-01-13), pages 1-25, XP015103991, [retrieved on 2015-01-13]
  • HALPERN J ET AL: "Service Function Chaining (SFC) Architecture; draft-ietf-sfc-architecture-09.txt", SERVICE FUNCTION CHAINING (SFC) ARCHITECTURE; DRAFT-IETF-SFC-ARCHITECTURE-09.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 8 June 2015 (2015-06-08), pages 1-29, XP015106573, [retrieved on 2015-06-08]
  • QUINN P ET AL: "Network Service Header; draft-ietf-sfc-nsh-00.txt", NETWORK SERVICE HEADER; DRAFT-IETF-SFC-NSH-00.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 24 March 2015 (2015-03-24), pages 1-42, XP015105659, [retrieved on 2015-03-24]
  
Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention).


Description

TECHNICAL FIELD



[0001] Disclosed herein are, for example, methods and network nodes for scalable mapping of tags to service function chain encapsulation headers.

BACKGROUND



[0002] A network service function is a middle box in a network that is responsible for a specific treatment of packets that it receives. The network service function can act on the received packets at one or multiple network/OSI layer(s) based on the intended functionality. There can be multiple such network service function middle boxes in a network providing different functionalities and/or multiple instances of the same functionalities. With the advent of NFV (Network Function Virtualization), the middle boxes are increasingly becoming virtualized, which helps in their flexible and on demand deployment in the network. Packets based on various policies, may be required to pass through a series of above-mentioned middle boxes. An ordered set of network service function middle boxes that packets must pass through is called service function chaining (also referred to as service chaining). Based on policy classification, a packet or a series of packets (also referred to as flow) might be required to follow a certain service chain. In a network, there can be multiple distinct service chains needed to realize various policy setting in a network. There can also be multiple instance of a service chain in order to balance load between instances of middle boxes that make up the service chains. It is also possible to have a middle box that is a part to multiple service chains.

[0003] A service chain may define an ordered set of service functions that must be applied to packets and/or frames selected as a result of classification. The implied order may not be a linear progression as the architecture allows for nodes that copy to more than one branch. Steering the traffic through the middle boxes in a service chain requires configuration of network forwarding elements - such as switches, routers, and Software Defined Networking (SDN) switches - along the path of the service chain for each packet flow. The forwarding rules not only define the path taken by the packet flow in the network but also the middle boxes the packet flow has to enter in the service chain. All these forwarding rules that have to be configured per flow in network forwarding elements can lead to increased states in these elements and can affect their internal lookup time required to forward packets.

[0004] The conventional approach to implementing service chaining is by installing flow rules in the network forwarding elements for each packet flow, which may not be efficient and flexible. Solutions to solve these problems are all based on appending a header to the packet that identifies the service chain that the packet should follow.

[0005] Another solution involves IETF Service Function Chain (SFC) Encapsulation. The IETF RFC 7665 specifies a set of architectural components that compose a service chain enabled domain, such as the SFC encapsulation. This encapsulation intends to insert a new protocol header that encapsulates the packets and guides them through the service functions (middle boxes) within service chains. The header includes the Service Function Path ID, and can additionally carry metadata including data plane context information. Two proposals are currently available for the SFC encapsulation: Network Service Header (NSH) and Service Chain Header (SFH).

[0006] Moreover, the SFC encapsulation requires service functions (middle) boxes to understand the new protocol (process the header) or use a proxy in the switches to do the same. However, SFC encapsulation is not suitable for regular network packet forwarding. Such forwarding relies on overlay technologies (e.g. VLAN, VxLAN, GRE, MPLS).

[0007] Another solution, efficient mobile service chaining, provides a scalable solution for mobility in combination with service chaining. The solution is based on the concept of a new core network architecture where a location registry is kept up-to-date with the current location of each mobile device. The location registry can be implemented in several ways, including in a distributed fashion.

[0008] Packets are marked with one or more tags, where a tag has a name and a value. The combination of tags defines the service chain and destination for that packet. Aggregation is achieved by using the same tag for multiple flows and multiple devices, thereby limiting the number of entries in the service chain forwarding elements. Packets are tagged by one or more classifiers.

[0009] At a mobility event, at least one classifier gets updated such that packets for that device get marked with the same tag names, but where one or more tags have an updated value. The updated value reflects the new location of the mobile device. Forwarding elements can be configured on how packets with a specific tag are to be forwarded. Most forwarding elements of this configuration, and in typical cases all configurations, do not need to be updated upon mobility events. This keeps the control signaling towards the forwarding elements to a minimum.

[0010] The conventional way to realize service chains, especially in SDN, is by installing forwarding rules for all the flows in the network. However this approach is very inefficient and results in an explosion of forwarding rules in the network forwarding elements, which might also affect the look up times while forwarding a packet.

[0011] The approach of using a single field of fixed size to identify the chain (in both NSH and SCH the Service Function Path ID - SFP ID - has a fixed size), can be a limiting factor, especially in mobility scenarios where a solution able to scale well is needed. Current proposals (e.g., IETF) have the underlying assumption that the service chaining is done outside mobile networks (i.e. above mobile anchor points, and in 3GPP technologies, above the PDN Gateway). However, being able to perform service chaining within the mobile network segment can bring several benefits, such as: to bring service functions closer to the end-users (such as in the Mobile Service Routing in a Network Environment case) inside the mobile network. However, this brings the complexity associated to the mobile network, such as the signaling required to update the chain due to mobility events. If one considers establishing service chains on a per-user basis, this further increases the burden on the network forwarding elements. Other traditional encapsulation technologies (e.g. MPLS, VLAN) cannot provide the required scalability either since they do not support appending multiple tags for chain identification.

[0012] The document "US 2014362857" relates to networking for service chains/service paths, and particularly to stacking metadata context for service chains.

[0013] The document "Function Chaining Use Cases in Mobile Network draft-ietf-sfc-use-case-mobility-09" provides some exemplary use cases for service function chaining in mobile service provider networks.

SUMMARY



[0014] The invention is defined by the independent claims. Furthermore, the embodiments of the invention are those defined by the claims. Moreover, examples and descriptions, which are not covered by the claims are presented not as embodiments of the invention, but as background art or examples useful for understanding the invention.

[0015] A method performed by a network node is provided as claimed in independent Claim 1.

[0016] A network node is provided as claimed in independent Claim 10. A computer program product is provided as claimed in independent Claim 11.

BRIEF DESCRIPTION OF THE DRAWINGS



[0017] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

Fig. 1 illustrates an exemplary wireless communication system according to some embodiments.

Fig. 2 illustrates an exemplary network architecture.

Fig. 3 illustrates an exemplary packet structure.

Fig. 4 illustrates an exemplary packet structure.

Fig. 5 illustrates an exemplary packet structure.

Fig. 6 illustrates an exemplary packet structure.

Fig. 7 is a flow chart illustrating a process according to some embodiments.

Fig. 8 is a block diagram of a control node according to some embodiments.

Fig. 9 is a block diagram of an access node according to some embodiments.

Fig. 10 is a block diagram of a UE according to some embodiments.

Fig. 11 is a functional diagram of a network node according to an embodiment of the invention.


DETAILED DESCRIPTION



[0018] Embodiments are directed to using an SFC Encapsulation header to extend scalability for a multiple tag solution. In some embodiments, multiple tags can be embedded in a SFC Encapsulation header (e.g., IETF, NSH, or SCH), which is used for SFC forwarding. Tag information can be based on, for example, the result of classification of the packet's 5-tuple, or on other aspects like geographical location, switch location, switch source port, etc.

[0019] As understood by one of ordinary skill in the art, embodiments are not limited to the IETF specifications and may include other specifications suitable for other types of encapsulation headers. Other embodiments may be done by relying on legacy technologies, such as VXLAN, VLAN, MPLS, or any other legacy technology known to one of ordinary skill in the art. A packet header includes a dedicated field used to take switching decisions (e.g., SFP ID in IETF NSH or SCH, or the VLAN ID in VLAN) combined with a variable-size field used to carry metadata (e.g., the metadata field in NSH or SCH, options in IPv6, etc).

[0020] Referring to Figure 1, a wireless communication deployment 100 in accordance with exemplary embodiments includes an access node 104 serving a wireless communication device (WCD) 106. Examples of WCDs include, but are not limited to, mobile telephones, user equipments (UEs), personal digital assistants, electronic readers, portable electronic tablets, wireless sensors, machine communication devices, personal computers, and laptop computers. Furthermore, the device 106 may be a legacy UE. Access node 104 may be, for example, a base station, an eNodeB, a WLAN Access Point, relay node, or gateway type device, and is capable of communicating with device 106, along with any additional elements suitable to support wireless communication between wireless communication devices or between a wireless communication device and another communication device, such as landline telephone. The access node 104 may be in communication with, for instance via a network 102, one or more control nodes 108, such as a Radio Network Controller (RNC), a Mobility Management Entity (MME), a Mobile Switching Center (MSC), a WLAN Access Gateway, evolved Packet Data Gateway (ePDG) or Base Station Subsystem (BSS). Although node 108 is explicitly identified as a control node, each of nodes 104, 106, and 108 may be understood as a "control" node to the extent that it includes a control unit or otherwise implements control functions.

[0021] Any number of tags can be embedded in a SFC Encapsulation header (e.g. IETF NSH, or SCH). Embodiments allow the ability to append multiple tags to a SFC Encapsulation header, and for packets to be forwarded based on those tags. Combining an arbitrary number of tags in the SFP ID field of the SFC Encapsulation Header is not possible since its scalability is limited due to the SFP ID fixed size of 24 bits. Embodiments disclosed herein enable the embedding of multiple tags in one or more metadata fields of the SFC Encapsulation Header, which supports variable length, and the embedding of one or more tags, or derived tags, in the SFP ID field. Furthermore, embodiments disclosed herein enable the ability to perform, along a flow path, the replacement of the information in the SFP ID by one or more tags or derived tags from the tag information in the metadata.

[0022] Fig. 2 illustrates a network architecture including a network transport layer 200 and a service function forwarding domain 202. The service function forwarding domain 202 includes at least four main entities: Service Function Forwarder (SFF)(206, 210, 214, 220), Classifier (CL)(204),Service Function (SF)(208, 212, 218, 222), and Tag Re-Mapper TRM (216).

[0023] The CL 204 performs initial classification of packets when entering or within the Service Function Forwarding domain 202. The initial classification procedure may include, for example, looking to the packet 5-tuple or any other packet header field, appending a SFC Encapsulation Header to a received packet, and assigning, based on customer/network/service specific policies, the correspondent SF Encapsulation information (i.e. SFP ID, metadata, etc). The CL 204 may also insert the multiple tags into the metadata field of the SFC Encapsulation header. The packet 5-tuple includes a source IP address, a destination IP address, a source port number, a destination port number, and a protocol in use.

[0024] The SFF entity is responsible for forwarding traffic to one or more connected SFs according to information carried in the SFC encapsulation, as well as handling traffic coming back from the SF. Furthermore, the SFF may be responsible for delivering traffic to a classifier when needed, transporting traffic to another SFF), and terminating the SFP.

[0025] A SF is responsible for specific treatment of received packets. A SF can act at various layers of a protocol stack (e.g., at the network layer or other OSI layers). Examples of treatments include, at the OSI layers, parental control or firewall, at the TCP level, at the IP level, packet counters, bandwidth limiters, functions to set QoS classes, and for functions below the IP level, radio air-link protocol handlers. The SF is responsible for a type of subscriber such as user classes (i.e., subscribers that have ordered the parental control user class get forwarded through that SF), end-service types (i.e., marking voice traffic as a high-priority), and radio access types (i.e., handling the PDCP (Packet Data Convergence Protocol) protocol). The split-up of the network as in the figure above, and the definition of SF, SFF, and CL all follow the IETF SFC draft.

[0026] The CL will take the set of tags or a subset of the tags and map it to a SFP ID. If there are few tags, then the SFP ID space (24 bits) may be enough to carry all the tags. The CL may also take a subset of the tags and map those to the SFP ID, or it could take a part of the information of one or more tags and make a SFP ID out of that. Embodiments may use either type of mapping based the number of tags and their length.

[0027] If it is not possible to map all tag information to a single SFP ID, then there may be one or more re-mappings in the middle of the service function chain. The re-mapping may be performed by a Tag Re-Mapper (TRM) 216. In some scenarios not every SFF needs to have a TRM. According to some embodiments, the TRM retrieves tags from the metadata and maps these to a new SFP ID. For example, as illustrated in Fig. 2, after the packet leaves the CL 204, the packet is forwarded according to SFP IDx. However, after leaving the TRM 216, the packet is forwarded according to SFP IDy. The mapping may be performed in the TRM in a similar way as in the classifier. Furthermore, although one TRM is illustrated in Fig. 2, it is understood by one of ordinary skill in the art that any desired number of TRM's may be included in the Service Function Forwarding domain 202, where a packet may be re-mapped any number of times.

[0028] The network architecture including the Service Function Forwarding layer 202 may be implemented, for example, in a Mobile Broadband offering that includes an end-to-end mobile service chaining mechanism. In this example, a tag is used in the downlink to denote the base station the user is currently attached to. As an example, the operator has 10,000 base stations. If every base station has a unique ID, then a tag of at least 14 bits is needed to encode these base stations (214=16,384).

[0029] The operator may deploy a number of service functions, SFs. These service functions could include, for example, NAT, firewall, bandwidth limiting, parental control, HTTP header enrichment, charging, TCP proxy, etc. As an example, there may be 20 such basic functions. If every function is either invoked or not, then this would already give 220≈ 1M different function chains. Additionally, there may be different chains that use a different order of the SFs. Furthermore, some functions are mandatory, some could be grouped, and far from all permutations of SFs will be valid. As an example, 20 bits will be enough to encode all possible service chains.

[0030] Encoding these bits in a single field would require 14+20=34 bits, which is too much for the 24-bits SFP ID field. Additionally each base station may be in a region, where there may be 20 regions in total. These 20 regions can be encoded in 5 bits. A region may refer to, but is not limited to, a geographical area, a group of base stations, a group of UE's, or any other group of network entities known to one of ordinary skill in the art.

[0031] In this example, there would be three tags: service ID (20 bits), base station ID (14 bits), and region ID (5 bits). In the beginning of the chain, the CL may derive a smaller service ID' of 19 bits from the original service ID of 20 bits. Combining this with the region ID of 5 bits gives a total of 24 bits, which the CL stores in the SFP ID. When the packet gets forwarded, it will eventually enter a specific region, where once in that region, a TRM changes the SFP ID. The TRM may derive a smaller service ID" from the service ID in the metadata. The service ID' may only be for the SFs that are still left to be traversed. As an example, the service ID' is 10 bits. The new SFP ID may contain the service ID' and the base station ID.

[0032] According to some embodiments, SFC encapsulation (e.g., NSH protocol, SCH protocol, or any other protocol that realizes SFC encapsulation) is used to encapsulate the tags. The metadata field in the SFC Encapsulation header hosts the full set of tags, and the SFP ID field hosts the primary forwarding tag. The SF forwarding may be performed on the SFP ID.

[0033] Fig. 3 illustrates an example packet that realizes SFC encapsulation. The packet includes an SFC Encapsulation Header, and may also include an IP Header followed by a transport layer header (e.g., TCP, UDP, etc.) and a payload section. Fig. 4 illustrates the packet with the SFC Encapsulation header expanded, which includes an SFP ID field and a metadata field.

[0034] The CL function may be implemented either as an SF, or as an SDN control mechanism, which uses SDN-enabled switches as well as the data plane interfaces (e.g. OpenFlow) to support SFC encapsulation protocols. As an example, the packet may be manipulated while a flow transverses the forwarding domain. Furthermore, all classification policies may be previously defined.

[0035] Fig. 5 illustrates an example of a packet that arrives at the CL for initial classification. As illustrated in Fig. 5, the packet does not include the SFC Encapsulation header prior to arriving at the CL. The CL determines if there are any policies that apply to the arrived packet based on, for example, information included in the headers or payload. If one or more policies apply to the arrived packet, the CL appends an SFC Encapsulation header to the packet and includes one or more tags in the metadata field of the SFC Encapsulation header. The tags may include a tag for a service treatment, a tag for a base station ID, and a tag for a region ID. Using one or more of the tags in the metadata field, the CL may generate a service ID that includes a region ID, where the service ID is inserted in the SFP field. The CL may use any of the tags included in the metadata field, and any subfield of a tag included in the metadata field, to generate the service ID. Fig. 6 illustrates an example of the packet after the CL appends the SFC Encap header to the packet.

[0036] A TRM performs a remapping of a packet having the SFC Encap Header and service ID generated by the CL. The TRM may be associated with a region ID included in the service ID in the SFP field. For example, when a packet traversing through the service chain reaches a particular region, the TRM for the region will check if the service ID contains the region ID for the TRM. If the service ID contains a matching region ID, the TRM retrieves one or more tags from the metadata field and generates a new service ID that is different than the service ID generated by the CL. As an example, the TRM may use a different tag, or at least one subfield of a tag not used by the CL to generate a service ID that is different than the service ID generated by the CL. The service ID generated by the TRM may contain a base station ID.

[0037] Fig. 7 illustrates an embodiment of a process performed by the TRM. The process may generally start at step 700 where the TRM receives, from a first portion of a service chain, a packet having a header portion that includes an a first service chain path ID and a metadata field. The process proceeds to step 702, where the TRM retrieves, according to one or more predefined rules, one or more tags included in the metadata field. The process proceeds to step 704, where the TRM generates a second service chain path ID based on the one or more retrieved tags. The process proceeds to step 706, where the TRM replaces the first service chain path ID by inserting the second service chain path ID in the header portion. After the TRM re-mapping process is completed, the packet may be forwarded, to a second portion of the service chain, in accordance with the second service chain path ID.

[0038] In some embodiments, the first service chain path ID is generated using at least one portion of a tag that is not used for generating the second service chain path ID. In some embodiments, the value of the first service chain path ID is different from the second service chain path ID generated from the retrieved one or more tags. The first service chain path ID indicates a first area, and the second service chain path ID indicates a second area.

[0039] The first and second areas indicate a topological set including one of: a geographical area, a base station set, and a UE set. The first service chain path ID indicates a first set of subscribers and the second service chain path ID indicates a second set of subscribers. The first and second subscribers are associated with at least one of: user classes, end-service types, and radio access types. In some embodiments, the first service chain path ID indicates a first service treatment and the second service chain path ID indicates a second service treatment.

[0040] The first and second service treatments specify one of: different sets of service functions, different return paths, different virtual network types, different instance types related to load balancing or replication. In some embodiments, the service chain path ID and metadata field are from a Service Function Chain Encapsulation header. In some embodiments, the length of the ID field is less than the length of the metadata field. In some embodiments, the length of the ID field is fixed and the length of the metadata field is non-fixed.

[0041] In some embodiments, the service path chain ID field is a Service Function Path ID field. The first and second portions of the service chains include one or more network service functions. In some embodiments, the one or more predefined rules are received from a network controller. The first service chain path ID is generated by another network node that did not generate the tags for the metadata field.

[0042] Fig. 8 is a block diagram of an embodiment of network node such as CL 204 or TRM 216. As shown in Fig. 8, the network node may include or consist of: a computer system (CS) 802, which may include one or more processors 855 (e.g., a general purpose microprocessor) and/or one or more circuits, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), a logic circuit, and the like; a network interface 803 for use in connecting the network node to a network; and a data storage system 806, which may include one or more non-volatile storage devices and/or one or more volatile storage devices (e.g., random access memory (RAM)). In embodiments where the network node includes a processor 855, a computer program product (CPP) 833 may be provided. CPP 833 includes or is a computer readable medium (CRM) 842 storing a computer program (CP) 843 comprising computer readable instructions (CRI) 844. CRM 842 is a non-transitory computer readable medium, such as, but not limited, to magnetic media (e.g., a hard disk), optical media (e.g., a DVD), solid state devices (e.g., random access memory (RAM), flash memory), and the like. In some embodiments, the CRI 844 of computer program 843 is configured such that when executed by computer system 802, the CRI causes the network node to perform steps described above (e.g., steps described above with reference to the flow charts and message flows shown in the drawings). In other embodiments, the network node may be configured to perform steps described herein without the need for a computer program. That is, for example, computer system 802 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.

[0043] FIG. 9 illustrates a block diagram of an exemplary access node, such as node 104 shown in Fig. 1. As shown in FIG. 9, the access node 104 may include: a data processing system 902, which may include one or more microprocessors and/or one or more circuits, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like; a network interface 903; a transceiver 905, coupled to an antenna, 922 for transmitting and receiving data and a data storage system 906, which may include one or more non-volatile storage devices and/or one or more volatile storage devices (e.g., random access memory (RAM)). In embodiments where the access node includes a processor 955, a computer program product (CPP) 933 may be provided. CPP 933 includes or is a computer readable medium (CRM) 942 storing a computer program (CP) 943 comprising computer readable instructions (CRI) 944. CRM 942 is a non-transitory computer readable medium, such as, but not limited, to magnetic media (e.g., a hard disk), optical media (e.g., a DVD), solid state devices (e.g., random access memory (RAM), flash memory), and the like. In some embodiments, the CRI 944 of computer program 943 is configured such that when executed by a data processing system 902, the CRI causes the access node to perform steps described above (e.g., steps described above with reference to the flow charts and message flows shown in the drawings). In other embodiments, the access node may be configured to perform steps described herein without the need for a computer program. That is, for example, a data processing system 902 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software. According to some embodiments, the data processing system 902 may comprise a control unit used for selection of transmission parameters.

[0044] In embodiments where data processing system 902 includes a microprocessor, computer readable program code (CRPC) may be stored in a computer readable medium, such as, but not limited, to magnetic media (e.g., a hard disk), optical media (e.g., a DVD), memory devices (e.g., random access memory), and the like. In some embodiments, computer readable program code is configured such that when executed by a processor, the code causes the data processing system 902 to perform steps described above (e.g., steps described above with reference to the flow charts shown above). In other embodiments, the access node 104 is configured to perform steps described herein without the need for code. That is, for example, data processing system 902 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software. For example, in particular embodiments, the functional components of the base station described above may be implemented by data processing system 902 executing computer instructions, by data processing system 902 operating independent of any computer instructions, or by any suitable combination of hardware and/or software.

[0045] Fig. 10 is a block diagram of UE such as a wireless communication device. As shown in Fig. 10, UE may include or consist of: a computer system (CS) 1002, which may include one or more processors 1055 (e.g., a general purpose microprocessor) and/or one or more circuits, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), a logic circuit, and the like; a transceiver 1005, coupled to an antenna, 1022 for transmitting and receiving data wirelessly; and a data storage system 1006, which may include one or more non-volatile storage devices and/or one or more volatile storage devices (e.g., random access memory (RAM)). Where UE includes a processor 1055, a computer program product (CPP) 1033 may be provided. CPP 1033 includes or is a computer readable medium (CRM) 1042 storing a computer program (CP) 1043 comprising computer readable instructions (CRI) 1044. CRM 1042 is a non-transitory computer readable medium, such as, but not limited, to magnetic media (e.g., a hard disk), optical media (e.g., a DVD), solid state devices (e.g., random access memory (RAM), flash memory), and the like. The CRI 1044 of computer program 1043 is configured such that when executed by computer system 1002, the CRI causes the UE to perform steps described above (e.g., steps described above with reference to the flow charts and message flows shown in the drawings). The UE may be configured to perform steps described herein without the need for a computer program. That is, for example, computer system 1002 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software. As shown in Fig. 10, UE may include: a display screen 1023, a speaker 1024, and a microphone 1025, all of which are coupled to CS 1002.

[0046] Figure 11 is a functional block diagram of a network node 1100 that is configured to perform steps described above (e.g., steps described above with reference to the flow charts and message flows shown in the drawings). The network node 1100 comprises a receiving module 1102 that is configured to receive, from a first portion of a service chain, a packet having a header portion that includes a first service chain path ID and a metadata field. The network node 1100 further comprises a retrieving module 1104 that is configured to retrieve one or more tags included in the metadata field, and a generating module 1106 that is configured to generate a second service chain path ID based on the one or more retrieved tags. The network node 1100 further comprises a replacing module 1108 that is configured to replace the first service chain path ID by inserting the second service chain path ID in the header portion.

[0047] It is to be noted that all modules 1102 to 1108 may be implemented as a one unit within an apparatus or as separate units or some of them may be combined to form one unit while some of them are implemented as separate units. In particular, all above described units might be comprised in one chipset or alternatively some or all of them might be comprised in different chipsets. In some implementations the above described modules might be implemented as a computer program product, e.g. in the form of a memory or as one or more computer programs executable from the memory of an apparatus.

[0048] The embodiments disclosed herein provide the significantly advantageous features of providing a solution that uses SFC protocols, extending the scalability of the SFC Encapsulation header by being able to embed and manage multiple tags, and not requiring a change to current proposals for SFC Encapsulation header.

[0049] In the above-description of various embodiments of present inventive concepts, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of present inventive concepts. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which present inventive concepts belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense expressly so defined herein.

[0050] When an element is referred to as being "connected", "coupled", "responsive", or variants thereof to another element, it can be directly connected, coupled, or responsive to the other element or intervening elements may be present. In contrast, when an element is referred to as being "directly connected", "directly coupled", "directly responsive", or variants thereof to another element, there are no intervening elements present. Like numbers refer to like elements throughout. Furthermore, "coupled", "connected", "responsive", or variants thereof as used herein may include wirelessly coupled, connected, or responsive. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and/or clarity. The term "and/or" includes any and all combinations of one or more of the associated listed items.

[0051] It will be understood that, although the terms first, second, third, etc. may be used herein to describe various elements/operations, these elements/operations should not be limited by these terms. These terms are only used to distinguish one element/operation from another element/operation. Thus, a first element/operation in some embodiments could be termed a second element/operation in other embodiments without departing from the teachings of present inventive concepts. The same reference numerals or the same reference designators denote the same or similar elements throughout the specification.

[0052] As used herein, the terms "comprise", "comprising", "comprises", "include", "including", "includes", "have", "has", "having", or variants thereof are open-ended, and include one or more stated features, integers, elements, steps, components or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions or groups thereof. Furthermore, as used herein, the common abbreviation "e.g.", which derives from the Latin phrase "exempli gratia," may be used to introduce or specify a general example or examples of a previously mentioned item, and is not intended to be limiting of such item. The common abbreviation "i.e.", which derives from the Latin phrase "id est," may be used to specify a particular item from a more general recitation.

[0053] Example embodiments are described herein with reference to block diagrams and/or flowchart illustrations of computer-implemented methods, apparatus (systems and/or devices) and/or non-transitory computer program products. It is understood that a block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and/or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions/acts specified in the block diagrams and/or flowchart block or blocks, and thereby create means (functionality) and/or structure for implementing the functions/acts specified in the block diagrams and/or flowchart block(s).

[0054] These computer program instructions may also be stored in a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks. Accordingly, embodiments of present inventive concepts may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.) that runs on a processor such as a digital signal processor, which may collectively be referred to as "circuitry," "a module" or variants thereof.

[0055] It should also be noted that in some alternate implementations, the functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Moreover, the functionality of a given block of the flowcharts and/or block diagrams may be separated into multiple blocks and/or the functionality of two or more blocks of the flowcharts and/or block diagrams may be at least partially integrated. Finally, other blocks may be added/inserted between the blocks that are illustrated, and/or blocks/operations may be omitted without departing from the scope of inventive concepts. Moreover, although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

[0056] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.

ABBREVIATIONS



[0057] 
CL
Classifier
GRE
Generic Routing Encapsulation
IETF
Internet Engineering Task Force
MPLS
Multiprotocol Label Switching
NFV
Network Function Virtualization
NSH
Network Service Header
SDN
Software Defined Networking
SF
Service Function
SFC
Service Function Chain
SFF
Service Function Forwarder
SCH
Service Chain Header
TRM
Tag Re-Mapper
VLAN
Virtual Local Area Network
VxLAN
Virtual Extensible Local Area Network



Claims

1. A method performed by a network node, the method comprising:

the network node receiving, from a first portion of a service chain, a packet having a header portion that includes a first service chain path ID and a metadata field;

the network node retrieving, according to one or more predefined rules, one or more tags included in the metadata field;

the network node generating a second service chain path ID based on the one or more retrieved tags; and

the network node replacing the first service chain path ID by inserting the second service chain path ID in the header portion,

wherein the packet is forwarded, to a second portion of the service chain, in accordance with the second service chain path ID, wherein the first service chain path ID indicates a first area, and the second service chain path ID indicates a second area, wherein the first and second areas indicate a topological set including one of a geographical area, a base station set, and a UE set.


 
2. The method according to claim 1, wherein the first service chain path ID is generated using at least one portion of a tag that is not used for generating the second service chain path ID.
 
3. The method according to claim 1, wherein the value of the first service chain path ID is different from the second service chain path ID generated from the retrieved one or more tags.
 
4. The method according to claim 1, wherein the service chain path ID and metadata field are from a Service Function Chain Encapsulation header.
 
5. The method according to claim 1, wherein the length of the ID field is less than the length of the metadata field.
 
6. The method according to claim 1, wherein the length of the ID field is fixed and the length of the metadata field is non-fixed.
 
7. The method according to claim 1, wherein the service path chain ID field is a Service Function Path ID field.
 
8. The method according to claim 1, wherein the first and second portions of the service chains include one or more network service functions.
 
9. The method according to claim 1, wherein the one or more predefined rules are received from a network controller.
 
10. A network node comprising:

a processor; and

a computer readable medium coupled to the processor, said computer readable medium containing instructions executable by the processor, whereby the network node is operative to: receive, from a first portion of a service chain, a packet having a header portion that includes a first service chain path ID and a metadata field, retrieve, according to one or more predefined rules, one or more tags included in the metadata field,

generate a second service chain path ID based on the one or more retrieved tags, and

replace the first service chain path ID by inserting the second service chain path ID in the header portion,

wherein the packet is forwarded, to a second portion of the service chain, in accordance with the second service chain path ID, wherein the first service chain path ID indicates a first area, and the second service chain path ID indicates a second area, wherein the first and second areas indicate a topological set including one of a geographical area, a base station set, and a UE set..


 
11. A computer program product comprising a non-transitory computer readable storage medium storing program code executable by a processor of the network node to cause the network node to perform the actions of the method of any one of claims 1 to 9.
 


Ansprüche

1. Verfahren, das durch einen Netzknoten durchgeführt wird, wobei das Verfahren umfasst:

Empfangen, durch den Netzknoten, von einem ersten Abschnitt einer Dienstkette, eines Pakets, das einen Header-Abschnitt aufweist, der eine erste Dienstkettenpfad-Kennung und ein Metadatenfeld einschließt;

Abrufen, durch den Netzknoten, nach einer oder mehreren vorgegebenen Regeln, eines oder mehrerer Tags, die in dem Metadatenfeld eingeschlossen sind;

Erzeugen, durch den Netzknoten, einer zweiten Dienstkettenpfad-Kennung basierend auf dem einen oder den mehreren abgerufenen Tags; und

Ersetzen, durch den Netzknoten, der ersten Dienstkettenpfad-Kennung durch Einfügen der zweiten Dienstkettenpfad-Kennung in den Header-Abschnitt,

wobei das Paket an einen zweiten Abschnitt der Dienstkette in Übereinstimmung mit der zweiten Dienstkettenpfad-Kennung weitergeleitet wird, wobei die erste Dienstkettenpfad-Kennung einen ersten Bereich angibt und die zweite Dienstkettenpfad-Kennung einen zweiten Bereich angibt, wobei die ersten und zweiten Bereiche einen topologischen Satz angeben, der eines von einem geografischen Bereich, einem Basisstationssatz und einem UE-Satz einschließt.


 
2. Verfahren nach Anspruch 1, wobei die erste Dienstkettenpfad-Kennung unter Verwendung von mindestens einem Abschnitt eines Tags erzeugt wird, der nicht zum Erzeugen der zweiten Dienstkettenpfad-Kennung verwendet wird.
 
3. Verfahren nach Anspruch 1, wobei der Wert der ersten Dienstkettenpfad-Kennung von der zweiten Dienstkettenpfad-Kennung verschieden ist, die aus dem einen oder den mehreren abgerufenen Tags erzeugt wird.
 
4. Verfahren nach Anspruch 1, wobei die Dienstkettenpfad-Kennung und das Metadatenfeld aus einem Dienstfunktionskettenverkapselungs-Header sind.
 
5. Verfahren nach Anspruch 1, wobei die Länge des Kennungsfeldes kleiner ist als die Länge des Metadatenfeldes.
 
6. Verfahren nach Anspruch 1, wobei die Länge des Kennungsfeldes fest ist und die Länge des Metadatenfeldes nicht fest ist.
 
7. Verfahren nach Anspruch 1, wobei das Dienstpfadketten-Kennungsfeld ein Dienstfunktionspfad-Kennungsfeld ist.
 
8. Verfahren nach Anspruch 1, wobei die ersten und zweiten Abschnitte der Dienstketten eine oder mehrere Netzwerkdienstfunktionen einschließen.
 
9. Verfahren nach Anspruch 1, wobei die eine oder die mehreren vorgegebenen Regeln von einer Netzwerksteuerung empfangen werden.
 
10. Netzknoten, umfassend:

einen Prozessor; und

ein von einem Computer lesbares Medium, das mit dem Prozessor gekoppelt ist, wobei das computerlesbare Medium Anweisungen enthält, die durch den Prozessor ausführbar sind, wobei der Netzknoten betriebsfähig ist zum: Empfangen, von einem ersten Abschnitt einer Dienstkette, eines Pakets mit einem Header-Abschnitt, der eine erste Dienstkettenpfad-Kennung und ein Metadatenfeld einschließt, Abrufen, nach einer oder mehreren vorgegebenen Regeln, eines oder mehrerer Tags, die in dem Metadatenfeld eingeschlossen sind,

Erzeugen einer zweiten Dienstkettenpfad-Kennung basierend auf dem einen oder den mehreren abgerufenen Tags und

Ersetzen der ersten Dienstkettenpfad-Kennung durch Einfügen der zweiten Dienstkettenpfad-Kennung in den Header-Abschnitt,

wobei das Paket an einen zweiten Abschnitt der Dienstkette in Übereinstimmung mit der zweiten Dienstkettenpfad-Kennung weitergeleitet wird, wobei die erste Dienstkettenpfad-Kennung einen ersten Bereich angibt und die zweite Dienstkettenpfad-Kennung einen zweiten Bereich angibt, wobei die ersten und zweiten Bereiche einen topologischen Satz angeben, der eines von einem geografischen Bereich, einem Basisstationssatz und einem UE-Satz einschließt.


 
11. Computerprogrammprodukt, umfassend ein nicht transitorisches computerlesbares Speichermedium, das Programmcode speichert, der durch einen Prozessor des Netzknotens ausführbar ist, um den Netzknoten zu veranlassen, die Aktionen des Verfahrens nach einem der Ansprüche 1 bis 9 durchzuführen.
 


Revendications

1. Procédé mis en œuvre par un nœud de réseau, le procédé comprenant :

le nœud de réseau recevant, depuis une première partie d'une chaîne de service, un paquet ayant une partie d'en-tête qui inclut un premier ID de trajet de chaîne de service et un champ de métadonnées ;

le nœud de réseau récupérant, selon une ou plusieurs règles prédéfinies, une ou plusieurs balises incluses dans le champ de métadonnées ;

le nœud de réseau générant un deuxième ID de trajet de chaîne de service sur la base de la ou des balises récupérées ; et

le nœud de réseau remplaçant le premier ID de trajet de chaîne de service en insérant le deuxième ID de trajet de chaîne de service dans la partie d'en-tête,

dans lequel le paquet est acheminé, à une deuxième partie de la chaîne de service, conformément au deuxième ID de trajet de chaîne de service, dans lequel le premier ID de trajet de chaîne de service indique une première zone, et le deuxième ID de trajet de chaîne de service indique une deuxième zone, dans lequel les première et deuxième zones indiquent un ensemble topologique incluant l'un parmi une zone géographique, un ensemble de stations de base, et un ensemble d'UE.


 
2. Procédé selon la revendication 1, dans lequel le premier ID de trajet de chaîne de service est généré en utilisant au moins une partie d'une balise qui n'est pas utilisée pour générer le deuxième ID de trajet de chaîne de service.
 
3. Procédé selon la revendication 1, dans lequel la valeur du premier ID de trajet de chaîne de service est différente du deuxième ID de trajet de chaîne de service généré à partir de la ou des balises récupérées.
 
4. Procédé selon la revendication 1, dans lequel l'ID de trajet de chaîne de service et le champ de métadonnées proviennent d'un en-tête d'encapsulation de chaîne de fonction de service.
 
5. Procédé selon la revendication 1, dans lequel la longueur du champ d'ID est inférieure à la longueur du champ de métadonnées.
 
6. Procédé selon la revendication 1, dans lequel la longueur du champ d'ID est fixe et la longueur du champ de métadonnées est non fixe.
 
7. Procédé selon la revendication 1, dans lequel le champ d'ID de chaîne de trajet de service est un champ d'ID de trajet de fonction de service.
 
8. Procédé selon la revendication 1, dans lequel les première et deuxième parties des chaînes de service incluent une ou plusieurs fonctions de service réseau.
 
9. Procédé selon la revendication 1, dans lequel la ou les règles prédéfinies sont reçues d'un contrôleur réseau.
 
10. Nœud de réseau comprenant :

un processeur ; et

un support lisible par ordinateur couplé au processeur, ledit support lisible par ordinateur contenant des instructions exécutables par le processeur, moyennant quoi le nœud de réseau est opérationnel pour : recevoir, depuis une première partie d'une chaîne de service, un paquet ayant une partie d'en-tête qui inclut un premier ID de trajet de chaîne de service et un champ de métadonnées, récupérer, selon une ou plusieurs règles prédéfinies, une ou plusieurs balises incluses dans le champ de métadonnées,

générer un deuxième ID de trajet de chaîne de service sur la base de la ou des balises récupérées, et

remplacer le premier ID de trajet de chaîne de service en insérant le deuxième ID de trajet de chaîne de service dans la partie d'en-tête,

dans lequel le paquet est acheminé, à une deuxième partie de la chaîne de service, conformément au deuxième ID de trajet de chaîne de service, dans lequel le premier ID de trajet de chaîne de service indique une première zone, et le deuxième ID de trajet de chaîne de service indique une deuxième zone, dans lequel les première et deuxième zones indiquent un ensemble topologique incluant l'un parmi une zone géographique, un ensemble de stations de base, et un ensemble d'UE.


 
11. Produit programme informatique comprenant un support de stockage non transitoire lisible par ordinateur stockant un code de programme exécutable par un processeur du nœud de réseau pour amener le nœud de réseau à mettre en œuvre les actions du procédé selon l'une quelconque des revendications 1 à 9.
 




Drawing




















Cited references

REFERENCES CITED IN THE DESCRIPTION



This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.

Patent documents cited in the description