US20150172422A1 - Systems and methods of header compression in a software defined network - Google Patents
Systems and methods of header compression in a software defined network Download PDFInfo
- Publication number
- US20150172422A1 US20150172422A1 US14/582,370 US201414582370A US2015172422A1 US 20150172422 A1 US20150172422 A1 US 20150172422A1 US 201414582370 A US201414582370 A US 201414582370A US 2015172422 A1 US2015172422 A1 US 2015172422A1
- Authority
- US
- United States
- Prior art keywords
- header
- packet
- data
- switch
- signal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000007906 compression Methods 0.000 title claims abstract description 17
- 230000006835 compression Effects 0.000 title claims abstract description 17
- 238000000034 method Methods 0.000 title description 7
- 230000004044 response Effects 0.000 claims abstract description 30
- 230000006837 decompression Effects 0.000 claims description 21
- 238000010586 diagram Methods 0.000 description 25
- 230000009471 action Effects 0.000 description 19
- 230000008901 benefit Effects 0.000 description 9
- 238000004891 communication Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 230000011664 signaling Effects 0.000 description 4
- 230000008569 process Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 1
- 238000013144 data compression Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 230000014616 translation Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/04—Protocols for data compression, e.g. ROHC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/54—Organization of routing tables
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/64—Routing or path finding of packets in data switching networks using an overlay routing layer
Definitions
- This invention relates generally to data compression and, more particularly, to systems and methods of header compression.
- the number of bits used for header information is a substantial percentage of the packet size and, in fact, can exceed the number of bits used for the voice payload.
- a first system includes circuitry configured to receive a first packet-header sent from a second system, the first packet-header having been sent in response to the second system receiving the first packet-header encapsulated in a frame, and the frame not matching a flow table entry in the second system.
- the first system also includes circuitry configured to send a first signal to the second system; circuitry configured to send a first flow table entry to the second system; circuitry configured to send a second signal to a third system; and circuitry configured to send a second flow table entry to the third system.
- the first signal causes the second system to generate substitute data in response to subsequently receiving a second packet-header, the substitute data being shorter that the second packet-header, the substitute data corresponding to the first signal, and the second signal causes the third system to generate the second packet-header, responsive to the substitute data subsequently received from the second system, in accordance with the second signal.
- a first system includes means for receiving, in a control plane, a first packet-header sent from a second system, the first packet-header having been sent in response to the second system receiving the first packet-header encapsulated in a frame in a data plane, and the frame not matching a flow table entry in the second system.
- the first system also includes means for sending, in the control plane, a first signal to the second system; means for sending, in the control plane, a first flow table entry to the second system; means for sending, in the control plane, a second signal to a third system; and means for sending, in the control plane, a second flow table entry to the third system.
- the first signal causes the second system to generate substitute data in response to subsequently receiving a second packet-header, the substitute data being shorter that the second packet-header, the substitute data corresponding to the first signal, and the second signal causes the third system to generate the second packet-header, responsive to the substitute data subsequently received from the second system, in accordance with the second signal.
- FIG. 1 is a diagram showing an exemplary system using header compression to effect a telephone call using a software defined network, in accordance with an exemplary embodiment of the present invention.
- FIG. 2 is a diagram showing a sequence of messages in the exemplary system.
- FIG. 3 is a diagram emphasizing a control plane in the exemplary system.
- FIG. 4 is diagram showing a data structure in ingress switch 110 , to link a flow table entry to a compression context.
- FIG. 5 is a diagram showing a compression context sent from a central controller to an ingress switch in the exemplary system.
- FIG. 6 is a diagram showing a compression context sent from the central controller to an egress switch in the exemplary system.
- FIG. 7 is a diagram showing data plane information received at the ingress switch.
- FIG. 8 is a diagram showing data plane information generated by the ingress switch and sent to the egress switch.
- FIG. 9 is diagram showing a data structure an egress switch, to link a flow table entry (or DLCI) to a decompression context.
- FIG. 10 is a diagram showing data plane information generated by the egress switch.
- FIG. 11 is a diagram showing an exemplary system in accordance with a second exemplary embodiment of the present invention.
- FIG. 12 is a diagram showing data plane information received at the ingress switch in the second exemplary system.
- FIG. 13 is a diagram showing data plane information generated by the ingress switch and sent to the egress switch in the second exemplary system
- FIG. 14 is a diagram showing data plane information generated by the egress switch in in the second exemplary system.
- FIG. 15 is a diagram showing an exemplary system in accordance with a third exemplary embodiment of the present invention.
- FIG. 16 is a diagram showing a sequence of messages in the exemplary system.
- FIG. 17 is a diagram emphasizing a control plane in the exemplary system.
- FIG. 18 is diagram showing a data structure in an egress switch, to link a flow table entry (or DLCI) to a decompression context.
- FIG. 19 is a diagram showing data plane information received at the ingress switch in the third exemplary system.
- FIG. 20 is a diagram showing data plane information generated by the ingress switch and sent to an intermediate switch in the third exemplary system.
- FIG. 21 is a diagram showing data plane information generated by the intermediate switch and sent to the egress switch in the third exemplary system
- FIG. 22 is a diagram showing data plane information generated by the egress switch in in the third exemplary system.
- FIG. 1 shows a communication system 1 according to an exemplary embodiment of the present invention.
- FIG. 1 emphasizes a data plane.
- Switches 110 , 120 , 140 , 130 are interconnected in a frame relay network.
- Switches 110 , 120 , 140 , 130 constitute a software defined network, that is part of an access network to the telephone system of the Acme Telephone Company.
- Network 5 is in communication with the ingress switch 110 .
- Network 5 is the global Internet.
- network 5 could be an analog PBX, another private IP (Internet Protocol) network etc.
- the owner of network 5 and the owner of Acme Telephone Company are non-affiliated, meaning that they are not affiliates with respect to each other.
- concerns are affiliates of each other when one concern controls or has the power to control the other, or a third party or parties controls or has the power to control both. Power to control is described in Section 121 of the U.S. regulations of the Small Business Administration.
- the egress switch 130 includes a physical inlet port 136 having physical port number 7, a physical outlet port 132 having physical port number 5, and a physical outlet port 134 having physical port number 0.
- a physical port is a switch defined port that corresponds to a hardware interface of the switch.
- the ingress switch 110 includes a physical inlet port 116 having physical port number 1, a physical outlet port 117 having physical port number 0, and a physical outlet port 119 having physical port number 2.
- the ingress switch 110 is typically separated from egress switch 130 by more than 1 kilometer.
- the ingress switch 110 includes an electronic memory that stores flow table 115 .
- flow table 115 includes the following entries:
- the flow table also controls how the switch handles the frame (priority for example, or another policy) as well as where the frame is sent (physical exit port).
- a person 15 places a telephone call to a person 30 via telephone circuitry 17 .
- the ingress switch 110 receives a frame on physical inlet port 116 ( FIG. 2 , message 1).
- the received frame encapsulates an OSI (Open Systems Interconnection) layer 3 header having a destination IP address 192.1.32.2.
- OSI Open Systems Interconnection
- circuitry encompasses dedicated hardware, and/or programmable hardware, such as a central processing unit (CPU) or reconfigurable logic array, in combination with programming data, such as sequentially fetched CPU instructions or programming data for a reconfigurable array.
- circuitry encompasses, for example, a general-purpose electronic processor programmed with software, acting to carry out a described function.
- Circuitry in the ingress switch 110 compares the incoming packet to each entry of the flow table 115 and, responsive to not detecting a match, forwards the packet header ( FIG. 2 , message 2) to controller 201 , shown in FIG. 3 .
- FIG. 3 emphasizes a control plane, with controller 201 communicating with switches 110 , 140 , 120 , and 130 via network interface hardware 368 .
- the controller 201 is typically separated from ingress switch 110 by more than 1 kilometer.
- the controller 201 is typically separated from egress switch 130 by more than 1 kilometer.
- control plane is a logical construct that can be implemented with hardware common to that used to implement the data plane, or can be implemented with hardware different from that used to implement the data plane.
- the controller 201 of the software defined network, includes a central processing unit 362 , a random access memory 364 , and network interface hardware 368 .
- Processor 362 executes program 317 stored in memory 364 , to receive, process, and generate various control plane messages.
- CPU 362 and program 317 act to search the DLCI allocation table 210 , to locate a currently unused data link connection identifier (DLCI) for a connection from ingress switch 110 .
- DLCI is a type of layer 2 destination address.
- An exemplary DLCI is 10 bits long.
- the controller 201 subsequently sends a compression context, and corresponding layer 2 header data, to the ingress switch 110 .
- the layer 2 header data includes an unused DLCI (having octal value 0570) found in allocation table 210 .
- the controller 201 sends a flow table entry, corresponding to the layer 2 header data, to the ingress switch 110 . ( FIG. 2 , message 5). Controller 201 may send messages 3 and 5 at the same time, in a common frame.
- the ingress switch 110 In response to message 5, the ingress switch 110 generates the following flow table 115 :
- the ingress switch 110 In response to receiving message 3, the ingress switch 110 generates the data structure shown in FIG. 4 , to associate the DLCI value 0570 with a compression context having patent application reference number 112 .
- the DLCI value 0570 acts as a context identifier.
- each reference is a data entity, stored in association with one (referencing) element, that enables a processor to find a related (referenced) element. To physically address the referenced element, the processor may subject the reference to various translations or mappings.
- FIG. 5 shows message 2 in more detail.
- Message 2 includes text data in XML format.
- the textual tag L3 designates OSI layer 3
- the textual tag L4 designates OSI layer 4.
- ingress switch 110 converts the text data to a binary format and stores the binary format in context table 112 shown in FIG. 4 .
- the controller 201 sends a decompression context, and the corresponding layer 2 header data, to the egress switch 130 . ( FIG. 2 , message 4).
- the controller 201 does not send digital samples of voice data (voice payload) to the egress switch 130 .
- the data sent by the controller 201 , to the egress switch 130 excludes part of the layer 4 packet received by the ingress switch 110 .
- the controller 201 does not send the length field of the layer 4 header to the egress switch 130 .
- the data sent by the controller 201 , to the egress switch 130 excludes part of the layer 4 header information received by the ingress switch 110 .
- the egress switch 130 In response to receiving message 4, the egress switch 130 generates the data structure shown in FIG. 9 , to associate DLCI 0570 with decompression context 114 .
- Decompression context 114 corresponds to compression context 112 .
- the DLCI acts as a context identifier.
- the decompression context 114 is the same as the compression context 112 .
- the controller 201 sends a flow table entry, corresponding to the layer 2 header data, to the egress switch 130 . ( FIG. 2 , message 7).
- the egress switch 13 In response to message 7, the egress switch 13 generates the following entry in flow table 135 .
- the controller 201 instructs the ingress switch to send PACKET 1. ( FIG. 2 , message 8).
- the ingress switch 110 replaces the headers, from layers 3 and 4, with their compressed equivalent, ( FIG. 2 , message 9), using Van Jacobson header compression, for example.
- the egress switch receives the layer 2 frame, and uses the layer 2 header to access the corresponding context, and decompress the frame, restoring the full headers for layers 3 and 4. ( FIG. 2 , message 11).
- Subsequent packets (messages 12) belonging to this flow are compressed by the switch 110 , and sent by the switch 110 , to the egress switch 130 (messages 13) without passing through the controller 201 .
- FIG. 7 shows a message 12 received at the ingress switch 110 .
- the message 12 includes a destination IP header address, and destination IP packet length.
- the switch 110 uses, inter alia, the IP header destination address to match the third entry in flow table 115 .
- switch 110 In response to matching the flow table entry, switch 110 replaces the IP header and UDP (User Datagram Protocol) header with a compressed IP header and a compressed UDP header.
- the compressed data does not include a destination IP address.
- the compressed IP header does not include a length of the IP packet.
- Switch 110 generates a message 13, shown in FIG. 2 , and in more detail in FIG. 8 .
- Message 13 does not include the IP header of message 12 or the UDP header of message 12.
- switch 130 uses, inter alia, the DLCI received in the message to match an entry in flow table 135 .
- Egress switch 130 also uses the DLCI to find a decompression context, in the database shown in FIG. 9 .
- egress switch 130 Responsive to the matching of the flow table entry, egress switch 130 replaces the compressed data with a complete IP header, and complete UDP header, thereby generating a message 15 shown in FIG. 2 , and in more detail in FIG. 10 .
- FIG. 11 shows a communication system 1 ′ according to another exemplary embodiment of the present invention.
- FIG. 12 is a diagram showing data plane information received at the ingress switch 110 ′.
- FIG. 13 is a diagram showing data plane information generated by the ingress switch 110 ′.
- FIG. 14 is a diagram showing data plane information generated by the egress switch 130 ′.
- the ingress switch 110 ′ instead of using Van Jacobson header compression for layers 3 and 4, the ingress switch 110 ′ does not send IP header data or UDP header data to the egress switch 130 ′.
- the switch 110 ′ sends, to the switch 130 ′, a frame that essentially includes only a DLCI, as the layer 2 header and context identifier, and a payload.
- FIG. 15 shows a communication system 1 ′′ according to another exemplary embodiment of the present invention.
- the third exemplary system has all the structure and functionality of the second exemplary system described above, plus the additional structure and functionality described below.
- the ingress switch 110 ′ does not send IP header data or UDP header data to the egress switch 130 ′. Instead, as shown in FIG. 20 , the switch 110 ′ sends a frame that essentially includes only a DLCI, acting as the layer 2 header, and a payload.
- the switch 140 ′ responsive to receiving the frame of FIG. 20 , the switch 140 ′ sends, to the switch 130 ′, a frame that essentially includes only a DLCI, acting as both the layer 2 header and context identifier, and a payload.
- the ingress switch 110 ′ includes a physical inlet port 116 having physical port number 1, a physical outlet port 117 having physical port number 0, and a physical outlet port 119 having physical port number 2.
- the ingress switch 110 ′ includes an electronic memory that stores flow table 115 .
- flow table 115 includes the following entries:
- the switch 140 ′ includes a physical inlet port 146 having physical port number 1, a physical outlet port 149 having physical port number 5, and a physical outlet port 148 having physical port number 2.
- the switch 140 ′ includes an electronic memory that stores flow table 145 .
- flow table 145 includes the following entries:
- a person 15 places a telephone call to a person 30 via telephone circuitry 17 .
- the ingress switch 110 ′ receives a frame on physical inlet port 116 ( FIG. 16 , message 1).
- the received frame encapsulates a layer 3 header having a destination IP address 192.1.32.2.
- Message 1 does not match any entry of flow table 115 at the time shown in FIG. 15 .
- Circuitry in the ingress switch 110 ′ compares the incoming packet to each entry of the flow table 115 and, responsive to not detecting a match, forwards the packet header ( FIG. 16 , message 2) to controller 201 ′′, shown in FIG. 17 .
- FIG. 17 emphasizes a control plane, with controller 201 ′′ communicating with switches 110 ′, 140 ′, 120 ′, and 130 ′ via network interface hardware 368 ′ and network 3 .
- Network 3 is different from the network shown in FIG. 15 that communicates data plane information.
- switch 110 ′ includes first circuitry configured to communicate with network 3 , and second circuitry configured to communicate with the data plane network shown in FIG. 15 .
- Switch 130 includes first circuitry configured to communicate with network 3 , and second circuitry configured to communicate with the data plane network shown in FIG. 15 .
- Switch 140 ′ includes first circuitry configured to communicate with network 3 , and second circuitry configured to communicate with the data plane network shown in FIG. 15 .
- the controller 201 ′′ includes programs 317 ′ stored in memory 364 , to receive, process, and generate various control plane messages.
- CPU 362 and programs 317 ′ act to search the DLCI allocation table 210 , to locate a currently unused data link connection identifier (DLCI) for a connection from ingress switch 110 ′.
- DLCI data link connection identifier
- CPU 362 and programs 317 ′ act to search the DLCI allocation table 212 , to locate a currently unused DLCI for a connection from switch 140 ′.
- controller 201 ′′ includes a DLCI allocation table for each connection between switches in the frame relay network shown in FIG. 15 .
- an intermediate switch such as switch 140 ′
- CPU 362 and programs 317 ′ act to search an additional DLCI allocation table, one corresponding to a connection from the intermediate switch.
- the controller 201 ′′ sends a flow table entry, corresponding to the layer 2 header data, to the ingress switch 110 ′. ( FIG. 2 , message 5).
- the flow table entry includes an unused DLCI (having octal value 0570) found in allocation table 210 .
- the ingress switch 110 ′ In response to message 5, the ingress switch 110 ′ generates the following flow table 115 :
- the controller 201 ′′ sends a flow table entry, corresponding to the layer 2 header data, to the switch 140 ′. ( FIG. 2 , message 6).
- the flow table entry includes an unused DLCI (having octal value 0375) found in allocation table 212 .
- the switch 140 ′ In response to message 6, the switch 140 ′ generates the following flow table 145 :
- the controller 201 ′′ sends a decompression context, and the corresponding layer 2 header data, to the egress switch 130 ′. ( FIG. 16 , message 4).
- the controller 201 ′′ sends the decompression context, and the corresponding layer 2 header data, to the egress switch 130 ′ via a signal path that excludes (bypasses) the ingress switch 110 ′.
- the egress switch 130 ′ In response to receiving message 4, the egress switch 130 ′ generates the data structure shown in FIG. 18 , to associate DLCI 0375 with decompression context 114 .
- the DLCI acts as a context identifier.
- the controller 201 also sends a flow table entry, corresponding to the layer 2 header data, to any intermediate switch(es).
- the intermediate switch matches a flow table entry in response to the DLCI received by the intermediate switch.
- This matching of the flow table entry, in the intermediate switch can cause the intermediate switch to forward the payload encapsulated by a frame having a DLCI destination field different from that used by the ingress switch to forward the frame to the intermediate switch.
- the egress switch receives the frame sent by the intermediate switch and, responsive to the DLCI written by the intermediate switch, selects a context that the egress switch uses to restore the uncompressed IP and UDP headers.
- the egress switch restores the IP and UDP headers using an identifier different from the DLCI sent by the ingress switch.
- the egress restores (generates) the IP and UDP headers using an identifier that was not sent by the ingress switch.
- the controller 201 sends a flow table entry, corresponding to the layer 2 header data, to the egress switch 130 ′. ( FIG. 2 , message 7).
- the egress switch 130 ′ In response to message 7, the egress switch 130 ′ generates the following entry in flow table 135 .
- the controller 201 ′′ instructs the ingress switch 110 ′ to send PACKET 1. ( FIG. 2 , message 8).
- the ingress switch 110 ′ replaces the headers, from layers 3 and 4, with a compressed equivalent ( FIG. 16 , message 9).
- the compressed equivalent is the DLCI 0570.
- the egress switch receives the layer 2 frame, sent by the intermediate switch 140 ′, and uses the layer 2 header to access the corresponding context, and decompress the frame, restoring the full headers for layers 3 and 4. ( FIG. 16 , message 11).
- Subsequent packets (messages 12) belonging to this flow are compressed by the switch 110 ′, and sent by the switch 110 ′, to the egress switch 130 ′, via intermediate switch 140 ′, (messages 13 and 14) without passing through the controller 201 .
- FIG. 19 shows a message 12 received at the ingress switch 110 ′.
- the message 12 includes a destination IP header address, and destination IP packet length.
- the switch 110 ′ uses, inter alia, the IP header destination address to match the third entry in flow table 115 .
- the length of the UDP header is 8 bytes, and the length of the IP header is 40 bytes.
- switch 110 ′ In response to matching the flow table entry, switch 110 ′ replaces the IP header with a compressed IP header and a compressed UDP header.
- the compressed data does not include a destination IP address.
- the compressed IP header does not include a length of the IP packet.
- Switch 110 ′ generates a message 13, shown in FIG. 2 , and in more detail in FIG. 20 .
- switch 140 ′ When switch 140 ′ received a message 13, switch 140 ′ uses the DLCI received in the message to match a flow table entry 145 . Switch 140 ′ then generates a message 14, shown in detail in FIG. 21 .
- switch 130 ′ When egress switch 130 ′ receives a message 14, switch 130 ′ uses, inter alia, the DLCI received in the message to match an entry in flow table 135 . Egress switch 130 also uses the DLCI to find a decompression context, in the database shown in FIG. 18 . More specifically, egress switch 130 ′ conditionally selects a decompression context, from among a plurality of decompression contexts, depending on whether the decompression context is stored in association with the DLCI.
- egress switch 130 Responsive to the matching of the flow table entry, egress switch 130 replaces the compressed data with a complete IP header, and complete UDP header, thereby generating a message 15 shown in FIG. 15 , and in more detail in FIG. 22 .
- the controller 201 ′′ is typically separated from ingress switch 110 ′ by more than 1 kilometer.
- the controller 201 ′′ is typically separated from egress switch 130 ′ by more than 1 kilometer.
- the ingress switch 110 ′ is typically separated from egress switch 130 ′ by more than 1 kilometer.
- the intermediate switch 140 ′ is typically separated from egress switch 130 ′, from ingress switch 110 ′, and from controller 201 ′′ by more than 1 kilometer.
- the controller 201 , the ingress switch 110 , and the egress switch 130 each include a type of processor in a software defined network.
- the controller 201 acts to receive, in a control plane, a packet header (in a Packet-in message) sent from the ingress switch 110 , the packet header having been sent in response to the ingress switch 110 receiving a packet in a data plane, and the packet header not matching a flow table entry in the ingress switch 110 .
- the controller 201 acts to send, in the control plane, an IP address and UDP address to the egress switch 130 , the IP address and UDP address acting as a context for decompression in egress switch 130 .
- the controller 130 encodes the IP address and UDP address as text, before sending the text to egress switch 130 .
- the controller 201 acts to send a flow table entry, containing a DLCI, which is a type of identifier, to the ingress switch 110 , to cause the ingress switch 110 to encapsulate data from network 5 in a frame relay frame including a destination field containing the DLCI.
- a frame relay frame is a type of data structure.
- the egress switch 130 acts to receive a frame from the ingress switch 110 and, responsive to the destination DLCI of the received frame, compare the received DLCI to a plurality of flow table entries stored in the egress switch 130 .
- the egress switch 130 selects a context for decompression, by using the DLCI of the received frame as an access key.
- the egress switch 130 generates an uncompressed IP header and uncompressed UDP header, using the selected context.
- the egress switch 130 As exemplified by messages 15 in FIG. 2 , the egress switch 130 generates uncompressed headers a plurality of times per each performance of the step of sending DLCI to egress switch 130 in message 4.
- the Ingress switch 110 compresses headers separately from any compression preformed on the voice payload data.
- the ingress switch 110 may act to compress data so that layer 3 and layer 4 headers are represented, in part, by a delta: a change from the previous value of a field rather than the current value.
- delta fields are encoded as the difference to the value in the previous packet in the same packet stream.
- the egress switch 130 then updates the context by adding the value in the compressed header to the value in its context. The result is the proper value of the field.
- the ingress switch 110 may act to compress data so that layer 3 and layer 4 headers are represented only by the context identifier (the DLCI).
- the DLCI context identifier
- all uncompressed IP header and UDP header fields are inferred from other values, for example the size of the frame carrying the packet, or from events, such as the number of frames received indicating the value of the time to live (TTL) field of the IP header.
- TTL time to live
- the controller 201 's sending of the DLCI causes the ingress switch 110 to send subsequently received data in compressed form.
- the compressed form includes digital samples of voice data encapsulated by a layer 2 header having the DLCI as the destination address.
- the controller does not send voice information to the egress switch
- the ingress switch forwards the entire first packet of a new flow to the controller, and the controller adds a decompression context and forwards the entire packet including digital samples of voice data (payload) to the egress switch.
- the time it takes to set up a connection and start the packet flow out of the egress switch is shortened.
- the ingress switch continues to forward entire packets of a new flow to the controller until establishment of the compression context, or other substitute data scheme, enables the ingress switch to send packets directly to the egress switch, thereafter bypassing the controller.
- the controller forwards those initial packets to the egress switch, with the decompression context for example. This could be useful for voice whose packets typically arrive every 20 ms; several packets could arrive during the time it takes the controller to calculate and deliver a context.
- the first packet that triggers the connection setup is a signaling packet that does not contain digital samples of voice data.
- the ingress switch recognizes the signaling packet, such as an INVITE message from an entity using the Session Initiation Protocol (SIP), H.323, or another signaling method.
- SIP Session Initiation Protocol
- the ingress switch in response to such a packet forwards the packet to the controller for parsing and action.
- One possible action is to set up a connection via entries in routing tables for the requested voice path while forwarding the signaling packet to the voice server responsible for the called phone number or SIP address.
- the ingress switch can have an appropriate entry already configured in the ingress switch routing table when the first packet containing a voice payload arrives, minimizing post-dial delay in setting up a call.
- a method including steps, performed by a first processor, of receiving a first packet-header sent from a second processor, the first packet-header having been sent in response to the second processor receiving the first packet-header encapsulated in a frame, and the frame not matching a flow table entry in the second processor; sending a first signal to the second processor; sending a first flow table entry to the second processor; sending a second signal to a third processor; and sending a second flow table entry to the third processor.
- Sending the first signal causes the second processor to generate substitute data in response to subsequently receiving a second packet-header, the substitute data being shorter that the second packet-header, the substitute data corresponding to the first signal, and sending the second signal causes the third processor to generate the second packet-header, responsive to the substitute data subsequently received from the second processor, in accordance with the second signal.
- the first signal can include an identifier for a compression context
- the second signal can include the identifier
- the first signal can include a layer 2 destination address
- the second signal can include the layer 2 destination address
- the first signal can include a layer 2 destination address
- the second signal can include the layer 2 destination address, wherein the layer 2 destination address acts as an identifier to allow the third processor to select a context for decompressing data.
- the second signal can include a context to be used to decompress subsequently received data.
- the first processor can sends the first signal and the first flow table entry, to the second processor, in a common frame, the common frame including a destination field.
- the second processor can constitute a network ingress switch including a plurality of exit ports, wherein the first flow table entry designates one of the plurality of exit ports.
- the first processor can send a first identifier to the second processor, to cause the second processor to encapsulate the packet header in a data structure including a destination field corresponding to the first identifier, wherein the first identifier can include a data link connection identifier.
- the packet received by the second processor can include payload data encapsulated by a layer 4 header, and the first processor does not send the payload data to the third processor.
- the packet received by the second processor can include a layer 4 header including payload length data, and the first processor does not send the payload length to the third processor.
- the second processor can receive a second packet; compare the received second packet to a plurality of flow table entries stored in the second processor; responsive to the comparing, select one of the plurality of flow table entries; compress the received second packet, in accordance with a context corresponding to the selected entry, to generate a compressed packet; and send the compressed packet, wherein the step of receiving a second packet is performed a plurality of times per each performance of the step of sending the first signal, and sending can include sending the compressed packet encapsulated in a frame relay frame.
- the first processor can act as a controller in a software defined network, the software defined network including a routing system, the second processor can act as an ingress switch in the software defined network, and the third processor can act as an egress switch in the software defined network, wherein the first processor sends a first identifier to the second processor, and the second processor receives a second packet encapsulating the received second packet in a data structure, the data structure including a destination field corresponding to the first identifier; sends the data structure to cause the routing system to be responsive to destination field, thereby sending the data structure to the third processor.
- the first processor can act as a controller in a software defined network, the software defined network including a routing system, the second processor can act as an ingress switch in the software defined network, and the third processor can act as an egress switch in the software defined network, wherein the second processor receives a second packet; compares the received second packet to a plurality of flow table entries stored in the second processor; responsive to the comparing step, selects one of the plurality of flow table entries; compresses the received second packet, in accordance with a context corresponding to the selected entry, to generate a compressed packet; encapsulates the received second packet in a data structure, the data structure including a destination field corresponding to the first identifier; and sends the data structure to cause the routing system to be responsive to destination field, thereby sending the data structure to the third processor.
- the first identifier can include a bit, wherein the routing system routes the data structure responsive to the bit, and the third processor selects a context responsive to the bit. 18 .
- the first identifier can include a plurality of bits, wherein the routing system routes the data structure response to each of the plurality of bits, and the third processor selects a context responsive to each of the plurality of bits.
- the second signal can include a context for decompression, the context including a layer 3 address encoded as text formatted as Extensible Markup Language (XML).
- XML Extensible Markup Language
- the first processor can act as a controller in a software defined network, the software defined network including a routing system, the second processor can act as an ingress switch in the software defined network, and the third processor can act as egress switch in the software defined network, wherein sending the second signal can include sending the second signal via a path that does not include the second processor.
- An instruction can be sent, in a control plane, to cause the second processor to send the packet header, in a data plane.
- the second processor can receives the packet from a network operated on behalf of a first entity, wherein the second processor is operated on behalf of a second entity, and the first entity is non-affiliated with the second entity,
- the substitute data can depend on the second packet-header.
- the substitute data can include a compressed form of the second packet-header.
- the first processor can be operated so as to not send digital samples of voice data to the third processor.
- the first packet-header can include header length data, and the first processor can be operated so as to not send the header length data to the third processor.
- the first packet-header can encapsulate digital samples of voice data.
- a DLCI has been exemplified as a header identifier or header decompression context identifier
- the role of such an identifier can be fulfilled by, for example, an MPLS label, or an ATM channel identifier.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
- This application is a continuation-in-part of pending U.S. patent application Ser. No. 14/142,804 of William A. FLANAGAN filed 24 Feb. 2013, the contents of which are herein incorporated by reference; which claims the benefit of U.S. Provisional Application 61/908,056 of William A. FLANAGAN filed 23 Nov. 2013, the contents of which are herein incorporated by reference.
- 1. Field of the Invention
- This invention relates generally to data compression and, more particularly, to systems and methods of header compression.
- 2. Description of Related Art
- In a typical voice over IP (Internet Protocol) process, the number of bits used for header information is a substantial percentage of the packet size and, in fact, can exceed the number of bits used for the voice payload.
- To address the problem above, a first system includes circuitry configured to receive a first packet-header sent from a second system, the first packet-header having been sent in response to the second system receiving the first packet-header encapsulated in a frame, and the frame not matching a flow table entry in the second system. The first system also includes circuitry configured to send a first signal to the second system; circuitry configured to send a first flow table entry to the second system; circuitry configured to send a second signal to a third system; and circuitry configured to send a second flow table entry to the third system. The first signal causes the second system to generate substitute data in response to subsequently receiving a second packet-header, the substitute data being shorter that the second packet-header, the substitute data corresponding to the first signal, and the second signal causes the third system to generate the second packet-header, responsive to the substitute data subsequently received from the second system, in accordance with the second signal.
- According to another aspect of the present invention, a first system includes means for receiving, in a control plane, a first packet-header sent from a second system, the first packet-header having been sent in response to the second system receiving the first packet-header encapsulated in a frame in a data plane, and the frame not matching a flow table entry in the second system. The first system also includes means for sending, in the control plane, a first signal to the second system; means for sending, in the control plane, a first flow table entry to the second system; means for sending, in the control plane, a second signal to a third system; and means for sending, in the control plane, a second flow table entry to the third system. The first signal causes the second system to generate substitute data in response to subsequently receiving a second packet-header, the substitute data being shorter that the second packet-header, the substitute data corresponding to the first signal, and the second signal causes the third system to generate the second packet-header, responsive to the substitute data subsequently received from the second system, in accordance with the second signal.
- References are made, in the following text, to the accompanying drawings, in which:
-
FIG. 1 is a diagram showing an exemplary system using header compression to effect a telephone call using a software defined network, in accordance with an exemplary embodiment of the present invention. -
FIG. 2 is a diagram showing a sequence of messages in the exemplary system. -
FIG. 3 is a diagram emphasizing a control plane in the exemplary system. -
FIG. 4 is diagram showing a data structure iningress switch 110, to link a flow table entry to a compression context. -
FIG. 5 is a diagram showing a compression context sent from a central controller to an ingress switch in the exemplary system. -
FIG. 6 is a diagram showing a compression context sent from the central controller to an egress switch in the exemplary system. -
FIG. 7 is a diagram showing data plane information received at the ingress switch. -
FIG. 8 is a diagram showing data plane information generated by the ingress switch and sent to the egress switch. -
FIG. 9 is diagram showing a data structure an egress switch, to link a flow table entry (or DLCI) to a decompression context. -
FIG. 10 is a diagram showing data plane information generated by the egress switch. -
FIG. 11 is a diagram showing an exemplary system in accordance with a second exemplary embodiment of the present invention. -
FIG. 12 is a diagram showing data plane information received at the ingress switch in the second exemplary system. -
FIG. 13 is a diagram showing data plane information generated by the ingress switch and sent to the egress switch in the second exemplary system -
FIG. 14 is a diagram showing data plane information generated by the egress switch in in the second exemplary system. -
FIG. 15 is a diagram showing an exemplary system in accordance with a third exemplary embodiment of the present invention. -
FIG. 16 is a diagram showing a sequence of messages in the exemplary system. -
FIG. 17 is a diagram emphasizing a control plane in the exemplary system. -
FIG. 18 is diagram showing a data structure in an egress switch, to link a flow table entry (or DLCI) to a decompression context. -
FIG. 19 is a diagram showing data plane information received at the ingress switch in the third exemplary system. -
FIG. 20 is a diagram showing data plane information generated by the ingress switch and sent to an intermediate switch in the third exemplary system. -
FIG. 21 is a diagram showing data plane information generated by the intermediate switch and sent to the egress switch in the third exemplary system -
FIG. 22 is a diagram showing data plane information generated by the egress switch in in the third exemplary system. - The accompanying drawings which are incorporated in and which constitute a part of this specification, illustrate embodiments of the invention and, together with the description, explain the principles of the invention, and additional advantages thereof. Certain drawings are not necessarily to scale, and certain features may be shown larger than relative actual size to facilitate a more clear description of those features. Throughout the drawings, corresponding elements are labeled with corresponding reference numbers.
-
FIG. 1 shows acommunication system 1 according to an exemplary embodiment of the present invention.FIG. 1 emphasizes a data plane. -
Switches Switches -
Network 5 is in communication with theingress switch 110. Network 5 is the global Internet. Alternatively,network 5 could be an analog PBX, another private IP (Internet Protocol) network etc. - The owner of
network 5 and the owner of Acme Telephone Company are non-affiliated, meaning that they are not affiliates with respect to each other. In this Patent Application, concerns are affiliates of each other when one concern controls or has the power to control the other, or a third party or parties controls or has the power to control both. Power to control is described inSection 121 of the U.S. regulations of the Small Business Administration. - The
egress switch 130 includes aphysical inlet port 136 havingphysical port number 7, aphysical outlet port 132 havingphysical port number 5, and aphysical outlet port 134 havingphysical port number 0. A physical port is a switch defined port that corresponds to a hardware interface of the switch. - The
ingress switch 110 includes aphysical inlet port 116 havingphysical port number 1, aphysical outlet port 117 havingphysical port number 0, and aphysical outlet port 119 havingphysical port number 2. Theingress switch 110 is typically separated fromegress switch 130 by more than 1 kilometer. - The
ingress switch 110 includes an electronic memory that stores flow table 115. At the time depicted inFIG. 1 , flow table 115 includes the following entries: - Values to be matched:
physical inlet port 1, destination IP address 192.103.45.27, destination UDP port 375 - Action: DLCI 0321, physical
outlet port number 2
Values to be matched:physical inlet port 1, destination IP address 192.103.45.37, destination UDP port 375
Action: DLCI 0164, physicaloutlet port number 2 -
- The flow table also controls how the switch handles the frame (priority for example, or another policy) as well as where the frame is sent (physical exit port).
- Subsequently, a
person 15 places a telephone call to aperson 30 viatelephone circuitry 17. As a result, theingress switch 110 receives a frame on physical inlet port 116 (FIG. 2 , message 1). The received frame encapsulates an OSI (Open Systems Interconnection)layer 3 header having a destination IP address 192.1.32.2.Message 1 does not match any entry of flow table 115 at the time shown above. - In this Patent Application, the word circuitry encompasses dedicated hardware, and/or programmable hardware, such as a central processing unit (CPU) or reconfigurable logic array, in combination with programming data, such as sequentially fetched CPU instructions or programming data for a reconfigurable array. Thus, circuitry encompasses, for example, a general-purpose electronic processor programmed with software, acting to carry out a described function.
- Circuitry in the
ingress switch 110 compares the incoming packet to each entry of the flow table 115 and, responsive to not detecting a match, forwards the packet header (FIG. 2 , message 2) tocontroller 201, shown inFIG. 3 . -
FIG. 3 emphasizes a control plane, withcontroller 201 communicating withswitches network interface hardware 368. Thecontroller 201 is typically separated fromingress switch 110 by more than 1 kilometer. Thecontroller 201 is typically separated fromegress switch 130 by more than 1 kilometer. - In this Patent Application, the control plane is a logical construct that can be implemented with hardware common to that used to implement the data plane, or can be implemented with hardware different from that used to implement the data plane.
- The
controller 201, of the software defined network, includes acentral processing unit 362, arandom access memory 364, andnetwork interface hardware 368. -
Processor 362 executesprogram 317 stored inmemory 364, to receive, process, and generate various control plane messages. - In response to
message 2,CPU 362 andprogram 317 act to search the DLCI allocation table 210, to locate a currently unused data link connection identifier (DLCI) for a connection fromingress switch 110. A DLCI is a type oflayer 2 destination address. An exemplary DLCI is 10 bits long. - The
controller 201 subsequently sends a compression context, andcorresponding layer 2 header data, to theingress switch 110. (FIG. 2 , message 3). Thelayer 2 header data includes an unused DLCI (having octal value 0570) found in allocation table 210. - The
controller 201 sends a flow table entry, corresponding to thelayer 2 header data, to theingress switch 110. (FIG. 2 , message 5).Controller 201 may sendmessages - In response to
message 5, theingress switch 110 generates the following flow table 115: - Values to be matched:
physical inlet port 1, destination IP address 192.103.45.27, destination UDP port 375
Action:DLCI 0321, physicaloutlet port number 2
Values to be matched:physical inlet port 1, destination IP address 192.103.45.37, destination UDP port 375 Action: DLCI 0164, physicaloutlet port number 2
Values to be matched:physical inlet port 1, destination IP address 192.1.32.2, destination UDP port 375
Action:DLCI 0570, physicaloutlet port number 2 -
- In response to receiving
message 3, theingress switch 110 generates the data structure shown inFIG. 4 , to associate theDLCI value 0570 with a compression context having patentapplication reference number 112. Thus, in effect, theDLCI value 0570 acts as a context identifier. - In the data structures shown in the figures, lines represent a reference, such as a pointer, between one element and another. These references are not necessarily direct memory address pointers. Instead, more generally, each reference is a data entity, stored in association with one (referencing) element, that enables a processor to find a related (referenced) element. To physically address the referenced element, the processor may subject the reference to various translations or mappings.
-
FIG. 5 showsmessage 2 in more detail.Message 2 includes text data in XML format. The textual tag L3 designatesOSI layer 3, and the textual tag L4 designatesOSI layer 4. - In response to receiving
message 2,ingress switch 110 converts the text data to a binary format and stores the binary format in context table 112 shown inFIG. 4 . - The
controller 201 sends a decompression context, and thecorresponding layer 2 header data, to theegress switch 130. (FIG. 2 , message 4). - The
controller 201 does not send digital samples of voice data (voice payload) to theegress switch 130. Thus, the data sent by thecontroller 201, to theegress switch 130, excludes part of thelayer 4 packet received by theingress switch 110. - The
controller 201 does not send the length field of thelayer 4 header to theegress switch 130. Thus, the data sent by thecontroller 201, to theegress switch 130, excludes part of thelayer 4 header information received by theingress switch 110. - In response to receiving
message 4, theegress switch 130 generates the data structure shown inFIG. 9 , to associateDLCI 0570 withdecompression context 114.Decompression context 114 corresponds tocompression context 112. Thus, in effect, the DLCI acts as a context identifier. - In this first exemplary embodiment, the
decompression context 114 is the same as thecompression context 112. - The
controller 201 sends a flow table entry, corresponding to thelayer 2 header data, to theegress switch 130. (FIG. 2 , message 7). - In response to
message 7, the egress switch 13 generates the following entry in flow table 135. - Values to be matched:
physical inlet port 7,layer 2address 0570
Action: physicaloutlet port number 0 -
- The
controller 201 instructs the ingress switch to sendPACKET 1. (FIG. 2 , message 8). - The
ingress switch 110 replaces the headers, fromlayers FIG. 2 , message 9), using Van Jacobson header compression, for example. - The egress switch receives the
layer 2 frame, and uses thelayer 2 header to access the corresponding context, and decompress the frame, restoring the full headers forlayers FIG. 2 , message 11). - Subsequent packets (messages 12) belonging to this flow (matching this flow table entry) are compressed by the
switch 110, and sent by theswitch 110, to the egress switch 130 (messages 13) without passing through thecontroller 201. - More specifically,
FIG. 7 shows amessage 12 received at theingress switch 110. Themessage 12 includes a destination IP header address, and destination IP packet length. Theswitch 110 uses, inter alia, the IP header destination address to match the third entry in flow table 115. - In response to matching the flow table entry,
switch 110 replaces the IP header and UDP (User Datagram Protocol) header with a compressed IP header and a compressed UDP header. The compressed data does not include a destination IP address. The compressed IP header does not include a length of the IP packet. -
Switch 110 generates a message 13, shown inFIG. 2 , and in more detail inFIG. 8 . Message 13 does not include the IP header ofmessage 12 or the UDP header ofmessage 12. - When
egress switch 130 receives a message 13,switch 130 uses, inter alia, the DLCI received in the message to match an entry in flow table 135.Egress switch 130 also uses the DLCI to find a decompression context, in the database shown inFIG. 9 . - Responsive to the matching of the flow table entry,
egress switch 130 replaces the compressed data with a complete IP header, and complete UDP header, thereby generating amessage 15 shown inFIG. 2 , and in more detail inFIG. 10 . -
FIG. 11 shows acommunication system 1′ according to another exemplary embodiment of the present invention. -
FIG. 12 is a diagram showing data plane information received at theingress switch 110′. -
FIG. 13 is a diagram showing data plane information generated by theingress switch 110′. -
FIG. 14 is a diagram showing data plane information generated by theegress switch 130′. - In the second exemplary system, instead of using Van Jacobson header compression for
layers ingress switch 110′ does not send IP header data or UDP header data to theegress switch 130′. - Instead, as shown in
FIG. 13 , theswitch 110′ sends, to theswitch 130′, a frame that essentially includes only a DLCI, as thelayer 2 header and context identifier, and a payload. -
FIG. 15 shows acommunication system 1″ according to another exemplary embodiment of the present invention. The third exemplary system has all the structure and functionality of the second exemplary system described above, plus the additional structure and functionality described below. - In the third exemplary system, the
ingress switch 110′ does not send IP header data or UDP header data to theegress switch 130′. Instead, as shown inFIG. 20 , theswitch 110′ sends a frame that essentially includes only a DLCI, acting as thelayer 2 header, and a payload. - As shown in
FIG. 21 , responsive to receiving the frame ofFIG. 20 , theswitch 140′ sends, to theswitch 130′, a frame that essentially includes only a DLCI, acting as both thelayer 2 header and context identifier, and a payload. - More specifically, the
ingress switch 110′ includes aphysical inlet port 116 havingphysical port number 1, aphysical outlet port 117 havingphysical port number 0, and aphysical outlet port 119 havingphysical port number 2. - The
ingress switch 110′ includes an electronic memory that stores flow table 115. At the time depicted inFIG. 15 , flow table 115 includes the following entries: - Values to be matched:
physical inlet port 1, destination IP address 192.103.45.27, destination UDP port 375 - Action:
DLCI 0321, physicaloutlet port number 2
Values to be matched:physical inlet port 1, destination IP address 192.103.45.37, destination UDP port 375
Action: DLCI 0164, physicaloutlet port number 2 -
- The
switch 140′ includes aphysical inlet port 146 havingphysical port number 1, aphysical outlet port 149 havingphysical port number 5, and aphysical outlet port 148 havingphysical port number 2. - The
switch 140′ includes an electronic memory that stores flow table 145. At the time depicted inFIG. 15 , flow table 145 includes the following entries: - Values to be matched:
physical inlet port 1,DLCI 0321
Action: DLCI 0322, physicaloutlet port number 5
Values to be matched:physical inlet port 1, DLCI 0164
Action: DLCI 0442, physicaloutlet port number 5 -
- Subsequently, a
person 15 places a telephone call to aperson 30 viatelephone circuitry 17. As a result, theingress switch 110′ receives a frame on physical inlet port 116 (FIG. 16 , message 1). The received frame encapsulates alayer 3 header having a destination IP address 192.1.32.2.Message 1 does not match any entry of flow table 115 at the time shown inFIG. 15 . - Circuitry in the
ingress switch 110′ compares the incoming packet to each entry of the flow table 115 and, responsive to not detecting a match, forwards the packet header (FIG. 16 , message 2) tocontroller 201″, shown inFIG. 17 . -
FIG. 17 emphasizes a control plane, withcontroller 201″ communicating withswitches 110′, 140′, 120′, and 130′ vianetwork interface hardware 368′ andnetwork 3.Network 3 is different from the network shown inFIG. 15 that communicates data plane information. Thus, switch 110′ includes first circuitry configured to communicate withnetwork 3, and second circuitry configured to communicate with the data plane network shown inFIG. 15 .Switch 130 includes first circuitry configured to communicate withnetwork 3, and second circuitry configured to communicate with the data plane network shown inFIG. 15 . Switch 140′ includes first circuitry configured to communicate withnetwork 3, and second circuitry configured to communicate with the data plane network shown inFIG. 15 . - The
controller 201″ includesprograms 317′ stored inmemory 364, to receive, process, and generate various control plane messages. - In response to
message 2,CPU 362 andprograms 317′ act to search the DLCI allocation table 210, to locate a currently unused data link connection identifier (DLCI) for a connection fromingress switch 110′. - In response to
message 2,CPU 362 andprograms 317′ act to search the DLCI allocation table 212, to locate a currently unused DLCI for a connection fromswitch 140′. - In general,
controller 201″ includes a DLCI allocation table for each connection between switches in the frame relay network shown inFIG. 15 . Thus, when an intermediate switch, such asswitch 140′, is in the path between the ingress switch and output switch,CPU 362 andprograms 317′ act to search an additional DLCI allocation table, one corresponding to a connection from the intermediate switch. - The
controller 201″ sends a flow table entry, corresponding to thelayer 2 header data, to theingress switch 110′. (FIG. 2 , message 5). The flow table entry includes an unused DLCI (having octal value 0570) found in allocation table 210. - In response to
message 5, theingress switch 110′ generates the following flow table 115: - Values to be matched:
physical inlet port 1, destination IP address 192.103.45.27, destination UDP port 375
Action:DLCI 0321, physicaloutlet port number 2
Values to be matched:physical inlet port 1, destination IP address 26.103.045.037, destination UDP port 375
Action: DLCI 0164, physicaloutlet port number 2
Values to be matched:physical inlet port 1, destination IP address 192.1.32.2, destination UDP port 375
Action:DLCI 0570, physicaloutlet port number 2 -
- The
controller 201″ sends a flow table entry, corresponding to thelayer 2 header data, to theswitch 140′. (FIG. 2 , message 6). The flow table entry includes an unused DLCI (having octal value 0375) found in allocation table 212. - In response to
message 6, theswitch 140′ generates the following flow table 145: - Values to be matched:
physical inlet port 1,DLCI 0321
Action: DLCI 0322, physicaloutlet port number 5
Values to be matched:physical inlet port 1, DLCI 0164
Action: DLCI 0442, physicaloutlet port number 5
Values to be matched:physical inlet port 1,DLCI 0570
Action:DLCI 0375, physicaloutlet port number 5 -
- The
controller 201″ sends a decompression context, and thecorresponding layer 2 header data, to theegress switch 130′. (FIG. 16 , message 4). Thecontroller 201″ sends the decompression context, and thecorresponding layer 2 header data, to theegress switch 130′ via a signal path that excludes (bypasses) theingress switch 110′. - In response to receiving
message 4, theegress switch 130′ generates the data structure shown inFIG. 18 , to associateDLCI 0375 withdecompression context 114. Thus, in effect, the DLCI acts as a context identifier. - In general, the
controller 201 also sends a flow table entry, corresponding to thelayer 2 header data, to any intermediate switch(es). In this case, when an intermediate switch subsequently receives a frame via the ingress switch, the intermediate switch matches a flow table entry in response to the DLCI received by the intermediate switch. This matching of the flow table entry, in the intermediate switch, can cause the intermediate switch to forward the payload encapsulated by a frame having a DLCI destination field different from that used by the ingress switch to forward the frame to the intermediate switch. Subsequently, the egress switch receives the frame sent by the intermediate switch and, responsive to the DLCI written by the intermediate switch, selects a context that the egress switch uses to restore the uncompressed IP and UDP headers. Thus, when the DLCI acts as a header identifier, the egress switch restores the IP and UDP headers using an identifier different from the DLCI sent by the ingress switch. In other words, the egress restores (generates) the IP and UDP headers using an identifier that was not sent by the ingress switch. - The
controller 201 sends a flow table entry, corresponding to thelayer 2 header data, to theegress switch 130′. (FIG. 2 , message 7). - In response to
message 7, theegress switch 130′ generates the following entry in flow table 135. - Values to be matched:
physical inlet port 7,DLCI 0375
Action: physicaloutlet port number 0 -
- The
controller 201″ instructs theingress switch 110′ to sendPACKET 1. (FIG. 2 , message 8). - The
ingress switch 110′ replaces the headers, fromlayers FIG. 16 , message 9). In this case, the compressed equivalent is theDLCI 0570. - The egress switch receives the
layer 2 frame, sent by theintermediate switch 140′, and uses thelayer 2 header to access the corresponding context, and decompress the frame, restoring the full headers forlayers FIG. 16 , message 11). - Subsequent packets (messages 12) belonging to this flow (matching this flow table entry) are compressed by the
switch 110′, and sent by theswitch 110′, to theegress switch 130′, viaintermediate switch 140′, (messages 13 and 14) without passing through thecontroller 201. - More specifically,
FIG. 19 shows amessage 12 received at theingress switch 110′. Themessage 12 includes a destination IP header address, and destination IP packet length. Theswitch 110′ uses, inter alia, the IP header destination address to match the third entry in flow table 115. - In
FIG. 19 , the length of the UDP header is 8 bytes, and the length of the IP header is 40 bytes. - In response to matching the flow table entry, switch 110′ replaces the IP header with a compressed IP header and a compressed UDP header. The compressed data does not include a destination IP address. The compressed IP header does not include a length of the IP packet.
- Switch 110′ generates a message 13, shown in
FIG. 2 , and in more detail inFIG. 20 . - When
switch 140′ received a message 13,switch 140′ uses the DLCI received in the message to match aflow table entry 145. Switch 140′ then generates a message 14, shown in detail inFIG. 21 . - When
egress switch 130′ receives a message 14,switch 130′ uses, inter alia, the DLCI received in the message to match an entry in flow table 135.Egress switch 130 also uses the DLCI to find a decompression context, in the database shown inFIG. 18 . More specifically,egress switch 130′ conditionally selects a decompression context, from among a plurality of decompression contexts, depending on whether the decompression context is stored in association with the DLCI. - Responsive to the matching of the flow table entry,
egress switch 130 replaces the compressed data with a complete IP header, and complete UDP header, thereby generating amessage 15 shown inFIG. 15 , and in more detail inFIG. 22 . - The
controller 201″ is typically separated fromingress switch 110′ by more than 1 kilometer. Thecontroller 201″ is typically separated fromegress switch 130′ by more than 1 kilometer. - The
ingress switch 110′ is typically separated fromegress switch 130′ by more than 1 kilometer. Theintermediate switch 140′ is typically separated fromegress switch 130′, fromingress switch 110′, and fromcontroller 201″ by more than 1 kilometer. - In summary, the
controller 201, theingress switch 110, and theegress switch 130, each include a type of processor in a software defined network. Thecontroller 201 acts to receive, in a control plane, a packet header (in a Packet-in message) sent from theingress switch 110, the packet header having been sent in response to theingress switch 110 receiving a packet in a data plane, and the packet header not matching a flow table entry in theingress switch 110. Thecontroller 201 acts to send, in the control plane, an IP address and UDP address to theegress switch 130, the IP address and UDP address acting as a context for decompression inegress switch 130. Thecontroller 130 encodes the IP address and UDP address as text, before sending the text to egressswitch 130. - The
controller 201 acts to send a flow table entry, containing a DLCI, which is a type of identifier, to theingress switch 110, to cause theingress switch 110 to encapsulate data fromnetwork 5 in a frame relay frame including a destination field containing the DLCI. A frame relay frame is a type of data structure. - The
egress switch 130 acts to receive a frame from theingress switch 110 and, responsive to the destination DLCI of the received frame, compare the received DLCI to a plurality of flow table entries stored in theegress switch 130. - Using the data structure shown in
FIG. 9 , theegress switch 130 selects a context for decompression, by using the DLCI of the received frame as an access key. Theegress switch 130 generates an uncompressed IP header and uncompressed UDP header, using the selected context. - As exemplified by
messages 15 inFIG. 2 , theegress switch 130 generates uncompressed headers a plurality of times per each performance of the step of sending DLCI to egressswitch 130 inmessage 4. - The
Ingress switch 110 compresses headers separately from any compression preformed on the voice payload data. - As exemplified in
FIGS. 7-8 , theingress switch 110 may act to compress data so thatlayer 3 andlayer 4 headers are represented, in part, by a delta: a change from the previous value of a field rather than the current value. In other words, delta fields are encoded as the difference to the value in the previous packet in the same packet stream. Theegress switch 130 then updates the context by adding the value in the compressed header to the value in its context. The result is the proper value of the field. - As exemplified in
FIGS. 12-14 , theingress switch 110 may act to compress data so thatlayer 3 andlayer 4 headers are represented only by the context identifier (the DLCI). In the case, all uncompressed IP header and UDP header fields are inferred from other values, for example the size of the frame carrying the packet, or from events, such as the number of frames received indicating the value of the time to live (TTL) field of the IP header. - Thus, the
controller 201's sending of the DLCI causes theingress switch 110 to send subsequently received data in compressed form. The compressed form includes digital samples of voice data encapsulated by alayer 2 header having the DLCI as the destination address. - Although, in an example described above, the controller does not send voice information to the egress switch, in an alternate embodiment of the invention, the ingress switch forwards the entire first packet of a new flow to the controller, and the controller adds a decompression context and forwards the entire packet including digital samples of voice data (payload) to the egress switch. Thus, the time it takes to set up a connection and start the packet flow out of the egress switch, is shortened.
- In another alternate embodiment, the ingress switch continues to forward entire packets of a new flow to the controller until establishment of the compression context, or other substitute data scheme, enables the ingress switch to send packets directly to the egress switch, thereafter bypassing the controller. The controller forwards those initial packets to the egress switch, with the decompression context for example. This could be useful for voice whose packets typically arrive every 20 ms; several packets could arrive during the time it takes the controller to calculate and deliver a context.
- In yet another alternate embodiment, the first packet that triggers the connection setup is a signaling packet that does not contain digital samples of voice data. Thus, the ingress switch recognizes the signaling packet, such as an INVITE message from an entity using the Session Initiation Protocol (SIP), H.323, or another signaling method. The ingress switch in response to such a packet forwards the packet to the controller for parsing and action. One possible action is to set up a connection via entries in routing tables for the requested voice path while forwarding the signaling packet to the voice server responsible for the called phone number or SIP address. In this case the ingress switch can have an appropriate entry already configured in the ingress switch routing table when the first packet containing a voice payload arrives, minimizing post-dial delay in setting up a call.
- Thus, there is a method including steps, performed by a first processor, of receiving a first packet-header sent from a second processor, the first packet-header having been sent in response to the second processor receiving the first packet-header encapsulated in a frame, and the frame not matching a flow table entry in the second processor; sending a first signal to the second processor; sending a first flow table entry to the second processor; sending a second signal to a third processor; and sending a second flow table entry to the third processor. Sending the first signal causes the second processor to generate substitute data in response to subsequently receiving a second packet-header, the substitute data being shorter that the second packet-header, the substitute data corresponding to the first signal, and sending the second signal causes the third processor to generate the second packet-header, responsive to the substitute data subsequently received from the second processor, in accordance with the second signal.
- The first signal can include an identifier for a compression context, and the second signal can include the identifier.
- The first signal can include a
layer 2 destination address, and the second signal can include thelayer 2 destination address. - The first signal can include a
layer 2 destination address, and the second signal can include thelayer 2 destination address, wherein thelayer 2 destination address acts as an identifier to allow the third processor to select a context for decompressing data. - The second signal can include a context to be used to decompress subsequently received data.
- The first processor can sends the first signal and the first flow table entry, to the second processor, in a common frame, the common frame including a destination field.
- The second processor can constitute a network ingress switch including a plurality of exit ports, wherein the first flow table entry designates one of the plurality of exit ports.
- The first processor can send a first identifier to the second processor, to cause the second processor to encapsulate the packet header in a data structure including a destination field corresponding to the first identifier, wherein the first identifier can include a data link connection identifier.
- The packet received by the second processor can include payload data encapsulated by a
layer 4 header, and the first processor does not send the payload data to the third processor. - The packet received by the second processor can include a
layer 4 header including payload length data, and the first processor does not send the payload length to the third processor. - The second processor can receive a second packet; compare the received second packet to a plurality of flow table entries stored in the second processor; responsive to the comparing, select one of the plurality of flow table entries; compress the received second packet, in accordance with a context corresponding to the selected entry, to generate a compressed packet; and send the compressed packet, wherein the step of receiving a second packet is performed a plurality of times per each performance of the step of sending the first signal, and sending can include sending the compressed packet encapsulated in a frame relay frame.
- The first processor can act as a controller in a software defined network, the software defined network including a routing system, the second processor can act as an ingress switch in the software defined network, and the third processor can act as an egress switch in the software defined network, wherein the first processor sends a first identifier to the second processor, and the second processor receives a second packet encapsulating the received second packet in a data structure, the data structure including a destination field corresponding to the first identifier; sends the data structure to cause the routing system to be responsive to destination field, thereby sending the data structure to the third processor.
- The first processor can act as a controller in a software defined network, the software defined network including a routing system, the second processor can act as an ingress switch in the software defined network, and the third processor can act as an egress switch in the software defined network, wherein the second processor receives a second packet; compares the received second packet to a plurality of flow table entries stored in the second processor; responsive to the comparing step, selects one of the plurality of flow table entries; compresses the received second packet, in accordance with a context corresponding to the selected entry, to generate a compressed packet; encapsulates the received second packet in a data structure, the data structure including a destination field corresponding to the first identifier; and sends the data structure to cause the routing system to be responsive to destination field, thereby sending the data structure to the third processor.
- The first identifier can include a bit, wherein the routing system routes the data structure responsive to the bit, and the third processor selects a context responsive to the bit. 18. The first identifier can include a plurality of bits, wherein the routing system routes the data structure response to each of the plurality of bits, and the third processor selects a context responsive to each of the plurality of bits.
- The second signal can include a context for decompression, the context including a
layer 3 address encoded as text formatted as Extensible Markup Language (XML). - The first processor can act as a controller in a software defined network, the software defined network including a routing system, the second processor can act as an ingress switch in the software defined network, and the third processor can act as egress switch in the software defined network, wherein sending the second signal can include sending the second signal via a path that does not include the second processor.
- An instruction can be sent, in a control plane, to cause the second processor to send the packet header, in a data plane.
- The second processor can receives the packet from a network operated on behalf of a first entity, wherein the second processor is operated on behalf of a second entity, and the first entity is non-affiliated with the second entity,
- The substitute data can depend on the second packet-header. The substitute data can include a compressed form of the second packet-header.
- The first processor can be operated so as to not send digital samples of voice data to the third processor.
- The first packet-header can include header length data, and the first processor can be operated so as to not send the header length data to the third processor.
- The first packet-header can encapsulate digital samples of voice data.
- Throughout this Patent Application, certain processing may be depicted in serial, parallel, or other fashion, for ease of description. Actual hardware and software realizations, however, may be varied depending on desired optimizations apparent to one of ordinary skill in the art.
- Benefits, other advantages, and solutions to problems have been described above with regard to specific examples. The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not critical, required, or essential feature or element of any of the claims.
- The invention in its broader aspects is therefore not limited to the specific details, representative apparatus, and illustrative examples shown and described. For example, although a DLCI has been exemplified as a header identifier or header decompression context identifier, the role of such an identifier can be fulfilled by, for example, an MPLS label, or an ATM channel identifier.
- Additional advantages and modifications will readily occur to those skilled in the art. Accordingly, departures may be made from such details without departing from the spirit or the scope of Applicants' general inventive concept. The invention is defined in the following claims. In general, the words “first,” “second,” etc., employed in the claims do not necessarily denote an order.
Claims (25)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/582,370 US9420071B2 (en) | 2013-11-23 | 2014-12-24 | Systems and methods of header compression in a software defined network |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201361908056P | 2013-11-23 | 2013-11-23 | |
US14/142,804 US8949467B1 (en) | 2013-11-23 | 2013-12-28 | Systems and methods of header compression in a software defined network |
US14/582,370 US9420071B2 (en) | 2013-11-23 | 2014-12-24 | Systems and methods of header compression in a software defined network |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/142,804 Continuation-In-Part US8949467B1 (en) | 2013-11-23 | 2013-12-28 | Systems and methods of header compression in a software defined network |
Publications (2)
Publication Number | Publication Date |
---|---|
US20150172422A1 true US20150172422A1 (en) | 2015-06-18 |
US9420071B2 US9420071B2 (en) | 2016-08-16 |
Family
ID=53369959
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/582,370 Active 2034-04-19 US9420071B2 (en) | 2013-11-23 | 2014-12-24 | Systems and methods of header compression in a software defined network |
Country Status (1)
Country | Link |
---|---|
US (1) | US9420071B2 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150319062A1 (en) * | 2014-05-05 | 2015-11-05 | Nicira, Inc. | Buffered subscriber tables for maintaining a consistent network state |
CN108055202A (en) * | 2017-12-07 | 2018-05-18 | 锐捷网络股份有限公司 | A kind of message processor and method |
JP2022549714A (en) * | 2019-09-27 | 2022-11-28 | ノキア テクノロジーズ オサケユイチア | Using Ethernet Header Compression with Robust Header Compression |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040107298A1 (en) * | 2002-08-14 | 2004-06-03 | Cedric Westphal | Layered compression architecture for multi-hop header compression |
US20110122893A1 (en) * | 2008-07-30 | 2011-05-26 | British Telecommunications Public Limited Company | Header compression scheme |
US20140169158A1 (en) * | 2012-12-17 | 2014-06-19 | Telefonaktiebolaget L M Ericsson (Publ) | Extending the reach and effectiveness of header compression in access networks using sdn |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6549533B1 (en) | 1998-12-30 | 2003-04-15 | Objective Systems Integrators | Managing switched virtual circuits in a network |
US6816483B1 (en) | 1999-07-16 | 2004-11-09 | Cisco Technology, Inc. | Switched virtual circuit call processing/routing system |
US7072296B2 (en) | 2002-08-02 | 2006-07-04 | Nms Communications Corporation | Methods and apparatus for network signal aggregation and bandwidth reduction |
US7602788B2 (en) | 2002-11-04 | 2009-10-13 | At&T Intellectual Property I, L.P. | Peer to peer SVC-based DSL service |
US20070041375A1 (en) | 2005-08-17 | 2007-02-22 | Cisco Technology, Inc. | System and method for implementing suppression for asynchronous transfer mode (ATM) adaptation layer 5 (AAL5) traffic in a communications environment |
US20070058539A1 (en) | 2005-08-17 | 2007-03-15 | Cisco Technology, Inc. | System and method for implementing suppression for asynchronous transfer mode (ATM) adaptation layer 2 (AAL2) traffic in a communications environment |
-
2014
- 2014-12-24 US US14/582,370 patent/US9420071B2/en active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040107298A1 (en) * | 2002-08-14 | 2004-06-03 | Cedric Westphal | Layered compression architecture for multi-hop header compression |
US20110122893A1 (en) * | 2008-07-30 | 2011-05-26 | British Telecommunications Public Limited Company | Header compression scheme |
US20140169158A1 (en) * | 2012-12-17 | 2014-06-19 | Telefonaktiebolaget L M Ericsson (Publ) | Extending the reach and effectiveness of header compression in access networks using sdn |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150319062A1 (en) * | 2014-05-05 | 2015-11-05 | Nicira, Inc. | Buffered subscriber tables for maintaining a consistent network state |
US9602422B2 (en) | 2014-05-05 | 2017-03-21 | Nicira, Inc. | Implementing fixed points in network state updates using generation numbers |
US10091120B2 (en) | 2014-05-05 | 2018-10-02 | Nicira, Inc. | Secondary input queues for maintaining a consistent network state |
US10164894B2 (en) * | 2014-05-05 | 2018-12-25 | Nicira, Inc. | Buffered subscriber tables for maintaining a consistent network state |
CN108055202A (en) * | 2017-12-07 | 2018-05-18 | 锐捷网络股份有限公司 | A kind of message processor and method |
JP2022549714A (en) * | 2019-09-27 | 2022-11-28 | ノキア テクノロジーズ オサケユイチア | Using Ethernet Header Compression with Robust Header Compression |
JP7365502B2 (en) | 2019-09-27 | 2023-10-19 | ノキア テクノロジーズ オサケユイチア | Combining Ethernet Header Compression with Robust Header Compression |
Also Published As
Publication number | Publication date |
---|---|
US9420071B2 (en) | 2016-08-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8949467B1 (en) | Systems and methods of header compression in a software defined network | |
JP4564228B2 (en) | Structure and method for transparently encoding and transmitting network communication data online and in cross session | |
US7002993B1 (en) | Method and apparatus providing media aggregation in a packet-switched network | |
US9019957B2 (en) | Network telephony system | |
US7961739B2 (en) | Systems and methods for voice over multiprotocol label switching | |
EP2852109B1 (en) | Service processing method, device and system | |
US8553692B2 (en) | Generic UDP multiplexing for voice over internet protocol (VOIP) | |
US6674744B1 (en) | Point-to-point data transport over the internet utilizing label switching without IP headers | |
US9420071B2 (en) | Systems and methods of header compression in a software defined network | |
US6954460B2 (en) | Method and apparatus for compressing packet headers | |
CN110035005B (en) | Data processing method and device | |
US8218569B2 (en) | Apparatus and method for terminating service emulation instances | |
US8559463B2 (en) | Systems and methods for providing efficient bandwidth utilization in packet switched networks | |
US20220158954A1 (en) | Virtual network device | |
US6975636B2 (en) | Voice over internet protocol gateway system and method therefor | |
US7643494B2 (en) | Interworking apparatus and method for accepting IP in WCDMA system | |
US20080123639A1 (en) | Relay apparatus and routing method | |
US20080123535A1 (en) | Maintenance apparatus, IP telephone system, and maintenance data transmission method | |
WO2014183525A1 (en) | Packet processing method and cascade chip | |
US8644314B2 (en) | Protocol and method of VIA field compression in session initiation protocol signaling for 3G wireless networks | |
US20060007925A1 (en) | Methods, systems, and computer program products for compressing a multiprotocol label switching (MPLS) shim header in a packet | |
WO2024021672A1 (en) | Multicast packet processing method and device, storage medium, and electronic device | |
CN110784513B (en) | Data mirroring method based on data frame of link layer | |
US8730852B2 (en) | Eliminating false audio associated with VoIP communications | |
Morais et al. | 5G Transport Payload: Ethernet-Based Packet-Switched Data |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO MICRO (ORIGINAL EVENT CODE: MICR); ENTITY STATUS OF PATENT OWNER: MICROENTITY |
|
FEPP | Fee payment procedure |
Free format text: SURCHARGE FOR LATE PAYMENT, MICRO ENTITY (ORIGINAL EVENT CODE: M3554); ENTITY STATUS OF PATENT OWNER: MICROENTITY |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, MICRO ENTITY (ORIGINAL EVENT CODE: M3551); ENTITY STATUS OF PATENT OWNER: MICROENTITY Year of fee payment: 4 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: MICROENTITY |
|
FEPP | Fee payment procedure |
Free format text: SURCHARGE FOR LATE PAYMENT, MICRO ENTITY (ORIGINAL EVENT CODE: M3555); ENTITY STATUS OF PATENT OWNER: MICROENTITY |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, MICRO ENTITY (ORIGINAL EVENT CODE: M3552); ENTITY STATUS OF PATENT OWNER: MICROENTITY Year of fee payment: 8 |