WO2014165278A1 - Extended packet switch and method for remote forwarding control and remote port identification - Google Patents

Abstract

An extended packet switch offers the transparent functionality of a packet switch appliance even when the ports are distant from the core switch. When the intervening access networks provide a plurality of logical connections, the connections are divided into port groups and assigned to individual ports on multiport end stations, with the receiver detecting the connection identifier and thence the originating port. Methods disclosed provide the core station with visibility into the source ports of ingress packets and with routing capability at the remote end stations. Embodiments include an extended packet switch, configurable like an ordinary switch appliance, operating simultaneously over multiple physical links.

Description

EXTENDED PACKET SWITCH AND METHOD FOR REMOTE FORWARDING

CONTROL AND REMOTE PORT IDENTIFICATION

RELATED APPLICATION DATA

The present application is related to, and claims the priority benefit of, commonly- as signed and co-pending United States Application Serial Numbers 61/777,105, entitled Wireless Network Providing Carrier Ethernet Services, filed on 12 March 2013 (12-03-2013); 61/822,294, entitled Connection-Oriented Software-Defined Network, filed on 5 May 2013 (05-05-2013); and 61/830,179, entitled Connection-Oriented Packet Switch, filed on 3 June 2013 (03-06-2013) June 3, 2013, which applications are incorporated herein by reference in their entireties. TECHNICAL FIELD

The present disclosure relates generally to packet switching and, in particular, to extended switches and associated methods.

BACKGROUND ART

The prior art packet switch 102 shown in Fig. 1 is commonly outfitted with ports 104 and is used to process ingress external data packets 106 of data arriving at said ports 104, transmitting relevant content of said ingress external data packets 106 as egress external data packets 108 switched to one or more said ports 104. In an appliance containing said packet switch 102, ports 104 are located in proximity to a core forwarding engine 110. Core forwarding engine 110 is capable of port identification in that is it enabled to discern the particular ingress port of arrival of data received from ingress packets 106 as it receives those packets. It is also capable of port forwarding, in that it is enable to impose the selection of the egress port on which packets it generates are delivered. This features enable core forwarding engine 110 to select ports 104 on the basis of useful information it collects, including the content of the ingress packets 106 and their relationship to the ports on they receive such information. Said core forwarding engine 110 may both read and consult a core forwarding database 112. Such use of said core forwarding database 112 provides the packet switch 102 with the ability to achieve Port Learning, in which it stores information accumulated from the historical record of the past arrival of ingress external data packets 106, associating certain elements of said ingress external data packets 106 with the port at which they arrived. Such Port Learning may be used to inform the Forwarding Control that directs egress to appropriate ports based on certain elements of said ingress external data packets 106. The core forwarding database 112 may also reflect configuration information, including information on the division of the switch into subsets, for example by separation into Virtual Local Area (VLAN) subsets that may be specified on the basis of ports, on the basis of packet VLAN tags, etc.

In some cases, it may be practical to expand the physical extent of packet switch 102 so that some ports are at a great distance from each other; that distance might be, for example, on the order of meters or kilometers. The result is the extended packet switch network 114 shown in Fig. 2. The ports are shown housed in end stations 116. Transmission interconnection may be provided to transmit the data content between the core station 118 (housing the core forwarding engine 110) and the remote end stations 116. Such transmission interconnections typically utilize, for example, metallic cables, optical-fiber cables, or wireless radio. Backhaul interconnection 120 provides the bidirectional transmission interconnection between the core forwarding engine and the remote end station. In such scenarios, Port Identification and Forwarding Control may be unavailable to the core forwarding engine 110. This may limit its ability to achieve Port Learning.

SUMMARY OF INVENTION

(1) TECHNICAL PROBLEM

A packet switch may be packaged as an appliance that can be purchased, installed, and operated by a switch user. However, in the extended packet switch network 114, a number of business issues may alter that situation. Many switch users lack the capability to effectively transmit data over long distances, such as among a set of office locations. Typically, a backhaul interconnection provider with capabilities including cables, fiber, or wireless connectivity may offer to provide a switching service, including operation and configuration of the core forwarding engine. Thus, some such switch users may be renters rather than owners of the switch they use, the backhaul interconnection may be nonideal, and the switch and backhaul interconnection may be shared with multiple services.

Switch service providers face challenges in providing appropriate service quality to a variety of customers and services, with differentiated service requirements, sharing backhaul interconnection, often with a link shared among users in a point- to-multipoint physical architecture. A switch service provider may agree with a customer to provide a specified service, with service assurances. In order to provide a specified service, however, the switch service provider may need to specify the separation point between customer responsibility and provider responsibility. In most cases, the specified point is at the port, which is the critical point of interchange. The port demarcates the extended packet switch network 114. The port is the point of interface between the extended packet switch network 114 and the attached user network. Commercial switch services specified by the Metro Ethernet Forum specify the port as the demarcation of service responsibilities.

In many cases, it is useful for the end station to incorporate a plurality of ports, as indicated in the prior art system of Fig. 2. Such a configuration may be of utility, for example, when the end station serves a variety of customers amenable to obtaining access at a single venue, such as within a single multitenant building. By providing separate ports, the switch service provider can provide individualized points of demarcation and individualized switching services to individual customers, or to separate networks of a single customer, without the need to provide a separate backhaul interconnection 120 for each said port. The packet switch 102 of Fig. 1 and the extended packet switch network 114 of Fig. 2 share a similar structure, but they offer quite different services. A technical problem involves adapting the prior art extended packet switch network system of Fig. 2 so that it functions as an Extended Packet Switch. The two scenarios can be distinguished on many factors, including:

• In the Extended Packet Switch, core forwarding engine 110 is able to ascertain the data ingress port at is receives a packet. It is therefore capable of Remote Port Identification. In the extended packet switch network of prior art, core forwarding engine 110 may be unable to discern the port at which data ingressed into the network. Hence, it may be incapable of Remote Port Identification.

• In the Extended Packet Switch, core forwarding engine 110 is able to specify, at the time it releases data, the egress port of data forwarded to end station 116. In other words, it is provided with Remote Forwarding Control. In the extended packet switch network of prior art, core forwarding engine 110 may be unaware of ports at the end station and is not able to specify forwarding to specific ports. Remote Forwarding Control has at least two aspects:

(a) VPN segmentation in an extended packet switch network may involve configuring a packet filter database in end station 116 with information regarding the relationship of packet tags to VPN ports, tagging packets to indicate their membership in a specific VPN. Such solutions have drawbacks. For example, extra packet tags add to the backhaul burden, extra tags require special processing that may be nonstandard or may not be included in typical equipment, and tags specified for insertion in standardized tag formats may be inconsistent with customer requirements. In the Extended Packet Switch, core forwarding engine 110 is able to specify the data egress port of data forwarded to the end station 116. Therefore, it has full control of port- based VPN segmentation, just as such a core forwarding engine 110 in a packet switching appliance would have.

(b) Regarding forwarding within the VPN, conventional switch technology may provide an additional forwarding capability in the end station, typically in the form of a learning switch or a programmable switch. Methods to remotely control the forwarding at such an end station switch are feasible with additional control and management functionality that could be problematic. Messages to implement such functionality that are carried over backhaul interconnection 120 are subject to delay, cost, and reliability issues. In the Extended Packet Switch, core forwarding engine 110 is able to specify the data egress port of data forwarded to the end station 116, so control of the core forwarding engine provides the port forwarding control. A controller distant from the end station (such as for example a Software-Defined Network (SDN) controller) may apply the capability to remotely impose forwarding decisions at the end station without direct control of communications across backhaul interconnection 120. (2) SOLUTION TO PROBLEM

The present disclosure provides Remote Forwarding Control, in which elements at the core station generate packets and provide direction to the end station specifying the selection of egress ports for forwarding the data content of those packets, considering both VPN segmentation and port selection within the VPN, without applying additional packet headers that introduce inefficiencies or restrict the switch user's transparent use of the services.

The present disclosure also provides Remote Port Identification, in which elements at the core station are informed, at receipt, of the ingress port at which data arriving at the core station originated. Without such identification, the core station will be unable to implement port learning techniques that can be used to populate the core forwarding database with information regarding the end station port associated with specific source packets. Some scenarios relevant to some embodiments of this disclosure are applicable to point-to- multipoint technologies sometimes used in network access deployments covering physical scales relevant to applications of the extended packet switch. A common aspect of many such architectures is a centralized base station unable to use physical sensing methods to distinguish the transmissions of a collection of individual remote stations, since the medium is shared. In order to distinguish the user transmissions received at the base station and to communicate directly with individual users, systems may divide the link using logical connections in a connection-oriented packet network. Such a scenario is widely employed and is an environment suitable for use of a Remote Packet Switch. The current disclosure shows how a plurality of connections, whether logical or physical, can be employed to exchange additional information among network elements that supports the methods of Remote Port Identification and Remote Port Forwarding. Other embodiments of the invention are also disclosed.

BRIEF DESCRIPTION OF DRAWINGS

Fig. 1 illustrates a block diagram of a prior art packet switch;

Fig. 2 illustrates a block diagram of a prior art extended packet switch network;

Fig. 3 illustrates a block diagram of an embodiment of a port extension system of the present disclosure;

Fig. 4A illustrates ESID lookup 153;

Fig. 4B illustrates port lookup 158;

Fig. 4C illustrates ESII lookup 160;

Fig. 4D illustrates ESOI lookup 162;

Fig. 4E illustrates I-LCID lookup 164;

Fig. 4F illustrates O-LCID lookup 166;

Fig. 4G illustrates inbound interface lookup 168;

Fig. 4H illustrates outbound interface lookup 170;

Fig. 5 illustrates inbound route database population procedure 172; Fig. 6 illustrates outbound route database population procedure 176;

Fig. 7 A illustrates inbound port route configuration procedure 180;

Fig. 7B illustrates inbound port route database 182;

Fig. 8 A illustrates outbound port route configuration procedure 184;

Fig. 8B illustrates outbound port route database 186;

Fig. 9 A illustrates ES ingress port route database establishment procedure 188;

Fig. 9B illustrates ES ingress port route database 190;

Fig. 10A illustrates ES egress port route database establishment procedure 192;

Fig. 10B illustrates ES egress port route database 194;

Fig. 11A illustrates CS inbound port lookup 196;

Fig. 11B illustrates CS outbound port set lookup 198;

Fig. l lC illustrates CS segment classification 200;

Fig. 12A illustrates ES inbound port set lookup 202;

Fig. 12B illustrates ES outbound port lookup 204;

Fig. 12C illustrates ES classification lookup 206;

Fig. 13 illustrates an embodiment of an ingress and inbound operation using the port extension system of Fig. 3;

Fig. 14 illustrates the sequence of steps of inbound operation and Remote Port Identification as shown in Fig. 13; Fig. 15 provides a flowchart of the core forwarding operation 214;

Fig. 16 illustrates an embodiment of an egress and outbound operation using the port extension system of Fig. 3; and

Fig. 17 illustrates the sequence steps of outbound operation and Remote Forwarding Control 216. DESCRIPTION OF EMBODIMENTS

The following description is presented to enable any person skilled in the art to make and use the embodiments. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles described herein are applicable to other embodiments and applications without departing from the spirit and scope of the present disclosure. Thus, the present invention is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

The numbers of entities shown in the drawings is for exemplification purposes only and does not indicate any restriction regarding the actual number of such entities. General structure

As indicated in Fig. 3, a port extension system 128 of the present disclosure includes an end station (ES) 116 and a core station (CS) 118. Said ES 116 is configured with one or more ports 104 into which users may transmit ingress external data packets 106 and receive egress external data packets 108. End station (ES) 116 is configured with packet processor 150. End station (ES) 116 is configured with ES memory 117. Packet processor 150 is enabled to read and write instructions and data from and to ES memory 117.

Core station (CS) 118 is configured with segment processor 151. Core station (CS) 118 is configured with core forwarding engine 110. CS 118 is configured with CS memory 119. Segment processor 151 and core forwarding engine 110 are both enabled to read and write from and to CS memory 119. Segment processor 151 and core forwarding engine 110 are enabled to exchange data.

As indicated in Fig. 3, said ES 116 and said CS 118 communicate by exchanging data over one or more pairs of links, each such pair including one inbound link 130 and one outbound link 132, where the terms "inbound" and "outbound" are taken from the perspective of the CS 118.

Although Fig. 3 shows said CS 118 related to a single ES 116, said CS 118 may be related to additional ESs 116 in a similar fashion. The particular ES 116 is identified at CS 118 by end station identifier (ESID) 152 that is globally unique among end stations communicating with CS 118. A database of ESID 152 for each ES 116 is retained within CS memory 119. Port Identifiers

As indicated in Fig. 3, each port 104 of ES 116 is identified by a local port identifier (LPID) 154 that is locally unique within the end station. Packet processor 150 is enabled to receive data from port 104 along with receiving associated identifier LPID 154. Packet processor 150 is enabled to direct data to port 104 based on knowledge of its associated identifier LPID 154. The list of LPIDs 154 of ports 104 at ES 116 is provided to CS 118 by any convenient method. This list is stored in CS memory 119 as a database associating each LPID 154 to the ES 152 of its ES 116.

Each port 104 is identified by a global port identifier (GPID) 156 that is globally unique among all ports of all end stations communicating with CS 118. Fig. 3 illustrates a naming system. In the example, the LPIDs 154 are integers unique within ES 116, and the GPIDs 156 are represented as the pair (ESID 152, LPID 154).

Internal Extension Links and Interfaces

This disclosure uses the term "data segment" in reference to internal data within the port extension system 128. This avoid confusion with the term "packet" in reference to external data.

As shown in Fig. 3, port extension system 128 is configured so that ES 116 is enabled to transmit inbound internal data segments 134 to CS 118 and CS 118 is enabled to transmit outbound internal data segments 136 to ES 116. Said inbound internal data segments 134 may be used to transfer the data content of said ingress external data packets 106 to CS 118, based on methods to be disclosed here. Data in said outbound internal data segments 136 may be transferred into egress external data packets 108, based on methods to be described here.

As shown in Fig. 3, for each inbound link 130, said ES 116 is configured with ES inbound link internal interface 138 enabled to transmit data to CS inbound link internal interface 140 at said CS 118. Said ES inbound link internal interface 138 is identified locally at ES 116 by ES inbound interface identifier (ESII-ID) 139. The assignment of ESII-ID to an ES inbound link internal interface 138 is unique within the ES. Said CS inbound link internal interface 140 is identified locally at CS 116 by CS inbound interface identifier (CSII-ID) 141. The assignment of CSII-ID 141 to CS inbound link internal interface 140 is unique within the CS.

As shown in Fig. 3, for each outbound link 132, said CS 118 is configured with one CS outbound link internal interface 144 enabled to transmit data to one ES outbound link internal interface 146 at said ES 116. Said CS outbound link internal interface 144 is identified locally at the CS by CS inbound interface identifier (CSII-ID) 145. The assignment of CSII-ID 145 to a CS outbound link internal interface 144 is unique within CS 118. Said ES outbound link internal interface 146 is identified locally at ES 116 by ES outbound interface identifier (ESOI-ID) 147. The assignment of ESOI-ID 148 to ES outbound link internal interface 146 is unique within ES 116. Segment processor 151 is enabled to receive data from CS inbound link internal interface 140 along with receiving associated identifier CSII-ID 141. Segment processor 151 is enabled to direct data to CS outbound link internal interface 144 given knowledge of associated identifier CSII-ID 145. Packet processor 150 is enabled to receive data from ES inbound link internal interface 146 along with receiving associated identifier ESOI-ID 147. Packet processor 150 is enabled to direct data to ES outbound link internal interface 138 given knowledge of associated identifier ESII-ID 139.

Both sides of the link are configured to exchange their link identifiers. With this information, CS memory 119 is provided with database records of the tuples (ESID 152, ESII-ID 139, CSII-ID 145) and (ESID 152, ESOI-ID 147, CSOI-ID 145).

Logical Connections

Inbound internal data segments 134 and outbound internal data segments 136 are transmitted on logical connections denoted by identifiers, as specified herein.

A set of I-LCIDs 142 is associated with each inbound link 130. A set of O-LCIDs 148 is associated with each outbound link 132. Logical connections may, in some embodiments, be implemented as segment headers, as suggested by the appearance of I-LCIDs 142 and O-LCID 148 in Fig. 3.

In some embodiments, delivery of said inbound internal data segment 134 to a particular inbound link internal interface 140 may vary in delivery service, timing, routing, etc. according to the specific I-LCID 142. In some embodiments, delivery of said outbound internal data segment 136 from a particular outbound link internal interface 144 may vary in delivery service, timing, routing, etc. according to the specific O-LCID 148.

One skilled in the art will recognize that the use of the I-LCID 142 and O-LCID 148 is represented in prior art, including systems based on standards such as EPON, EPOC, GPON, DOCSIS Provisioning of EPON (DPoE), IEEE Std 802.16, 3GPP LTE, etc. In such systems, such logical connection identifiers are not used for Remote Port Identification or Remote Forwarding Control, as disclosed herein, but for other purposes. This disclosure makes additional use of the logical connection identifiers by methods disclosed herein.

Databases and Lookup Functions ES memory 117 and CS memory 119 are enabled to support data storage. Data lookup functionality is provided. Each lookup is a function that accepts specified input and returns specified output. Lookup functionality in CS 118 could be provided by segment processor 151 or a separate processor. Lookup functionality in ES 116 could be provided by packet processor 150 or a separate processor. The methods herein are not limited to particular implementation of the data storage or lookup functionality.

Basic CS Databases and Lookups

Basic CS lookups are illustrated in Fig. 4. In Fig. 4, and other figures of this disclosure, the lookups are illustrated by diagrams in which fields of both the input and the output of the lookup are listed on the upper side of the diagram. Input fields are to the left side of the diagrams, and output (return) fields are on the right. In the rectangles below the field labels, arrows are used to illustrated the operation of the lookup. Arrows entering at the left indicate that the field including the arrowhead is an input field. Arrows leaving at the right indicate that the field including the arrow tail is an output field. As indicated, some lookups include multiple fields as inputs and outputs. A single arrowhead at the output indicates that a single response to the lookup is expected. A double arrowhead at the output indicates that a list may be anticipated. Basic lookups executable at the CS are described below.

ESID lookup 153 takes no input. It returns the list of ESIDs.

Port lookup 158 takes as input ESID 152. It returns the list of LPIDs affiliated with the particular ES 116 identified by the input ESID 152. ESII lookup 160 takes as input ESID 152. It returns the list of ESII-IDs 139 affiliated with the particular ES 116 identified by the input ESID 152.

ESOI lookup 162 takes as input ESID 152. It returns the list of ESOI-IDs 147 affiliated with the particular ES 116 identified by the input ESID 152. I-LCID lookup 164 takes as input ESID 152 and ESII-ID 139. It returns the list of I-LCIDs 142 that are affiliated with the particular ES 116 identified by the input ESID 152 and are also affiliated with the particular ES inbound link internal interface 138 identified by the input ESII- ID 139. O-LCID lookup 166 takes as input ESID 152 and ESOI-ID 147. It returns the list of O-LCIDs 148 that are affiliated with the particular ES 116 identified by the input ESID 152 and are also affiliated with the particular ES outbound link internal interface 146 identified by the input ESOI-ID 147.

Inbound interface lookup 168 takes as input ESID 152 and ESII-ID 139. It returns the sole CSII-ID 141 that is associated with ESII-ID 139 by virtue of their common relationship to inbound link 130.

Outbound interface lookup 170 takes as input ESID 152 and ESOI-ID 147. It returns the sole CSOI-ID 145 that is associated with ESOI-ID 147 by virtue of their common relationship to outbound link 132. Route databases and compilation procedures

As shown in Fig. 5, inbound route database population procedure 172 is used to populate CS memory 117 with inbound route table 174. This procedure is detailed in the form of pseudocode that will be readily understood by the practitioner. This procedure may be executed by segment processor 151. Fig. 5 also shows the fields included in inbound route database 174. As shown in Fig. 6, outbound route database population procedure 176 is used to populate CS memory 117 with outbound route database 178. This procedure is detailed in the form of pseudocode that will be readily understood by the practitioner. This procedure may be executed by segment processor 151. Fig. 6 also shows the fields included in inbound route database 178.

CS port route procedures and bindings As shown in the flowchart of Fig. 7A, inbound port route configuration procedure 180 is used to establish inbound port route database 182 that binds routes to ports. The procedure could be executed by segment processor 151. Inbound port route configuration procedure 180 takes input from provided inbound port assignment configuration table 181 , which takes the form shown in TABLE I. TABLE I (181)

Inbound port route configuration procedure 180 binds the routes to ports. The process starts at step 700 and quickly proceeds to step 701 , at which inbound port route database 182 in CS memory 19 is initialized. At step 702, provided inbound port assignment configuration table 181 is read from a storage location, which could be CS memory 119. Step 704 initializes a loop through the rows of the configuration table. In step 706, ESID 152 and ESII-ID 139 from the row are passed to lookup 168, which returns CSII-ID 141 in step 708. In Step 710, field of the row as read, plus CSII-ID 141 , are written to a row of inbound port route database 182 in CS memory 19. Step 712 increments the row, and step 714 moves to the next row or to step 716 at the end of the table. The resulting inbound port route database 182 in CS memory 19 is illustrated Fig. 7B.

As shown in the flowchart of Fig. 8 A, outbound port route configuration procedure 184 is used to configure outbound port route database 186. Outbound port route configuration procedure 184 takes input from provided outbound port assignment configuration 185, which takes the form shown in TABLE II.

TABLE II (185)

LPID is specified as a compound field in TABLE II (185), so it can encompass a set of scalar values of LPID 154. This provides the possibility to use an O-LCID 148 logical channel for multicast or broadcast within ES 116. See also step 1716 of procedure 216. If no assignment of a particular ESOI-ID 147 and O-LCID 148 is made to the particular ES 116 identified by ESID 152, then that particular ES 116 is not intended to receive on that ESOI-ID 147 and O-LCID 148.

The process starts at step 800. In step 801 , outbound port route database 186 in CS memory 19 is initialized. At step 802, provided outbound port assignment configuration table 185 is read from a storage location, which could be CS memory 119. Step 804 initializes a loop through the rows of the configuration table. In step 806, ESID 152 and ESOI-ID 147 from the row are passed to lookup 170, which returns CSOI-ID 145 in step 808. In Step 810, fields of the row as read, plus CSOI-ID 145, are written to a row of outbound port route database 186 in CS memory 119. Step 812 increments the row, and step 814 moves to the next row or to step 816 at the end of the table. The resulting inbound port route database 182 in CS memory 119 is illustrated Fig. 7B. This procedure could be executed by segment processor 151.

ES port route procedures and databases

As shown in Fig. 9A, ES ingress port route database establishment procedure 188 is used to configure ES ingress port route database 190. The procedure begins at step 900. At step 902, inbound port route database 182 is read from CS memory 119. At step 904, ES ingress port route database 190 in ES memory 117 is initialized for each ES 116 identified by each ESID 152 field of each row. Step 906 initializes a loop through the rows of inbound port route database 182. In step 908, the current row (excluding the ESID 152 field) is duplicated to a new row of ES ingress port route database 190 in ES memory 117 of ES 116 identified by the ESID 152 field of the row. Step 910 increments. Step 912 loops or moves terminate at step 914. The resulting ES ingress port route database 190 in ES memory 117 is illustrated Fig. 9B.

As shown in Fig. 10A, ES egress port route database establishment procedure 192 is used to configure ES egress port route database 194. The procedure begins at step 1000. At step 1002, inbound port route database 182 is read from CS memory 119. At step 1004, ES egress port route database 194 in ES memory 117 is initialized for each ES 116 identified by each ESID 152 field of each row. Step 1006 initializes a loop through the rows of inbound port route database 182. In step 1008, the current row (excluding the ESID 152 field) is duplicated to a new row of ES egress port route database 194 in ES memory 117 of ES 116 identified by the ESID 152 field of the row. Step 1010 increments. Step 1012 loops or moves terminate at step 1014. The resulting ES egress port route database 194 in ES memory 117 is illustrated Fig. 10B. CS Port lookups

CS port lookup procedures are provided.

As shown in Fig. 11 A, CS inbound port lookup 196 takes two inputs (CSII-ID 141 , and I-LCID 142). It returns a single compound result (ESID 152, LPID 154). CS inbound port lookup 196 can be constructed by search of inbound port route database 182, which is stored in stored in CS memory 119.

As shown in Fig. 11B, CS inbound port set lookup 198 takes two inputs (ESID 152 and LPID 154). It returns a list of pairs (CSOI-ID 145, O-LCID 148). CS inbound port lookup 198 can be constructed by search of inbound port route database 186, which is stored in stored in CS memory 119.

CS Segment classification

As shown in Fig. 11C, CS segment classification 200 takes three inputs (forwarding data segment 137, I-GPID 157, and E-GPID 159), returning outbound internal data segment 136 along with a route (CSOI-ID 145, O-LCID 148) to ES 116. The details of CS segment classification 200 are not specified here. Many techniques are available.

CS segment classification 200 may drop a packet by not returning a segment. Because I-GPID 157 and E-GPID 159 are both available to CS segment classification 200, various packet filtering and VLAN techniques are applicable.

ES Port lookups ES port lookup procedures are provided.

As shown in Fig. 12A, ES inbound port set lookup 202 takes one input (LPID 154). It returns a list of pairs (ESII-ID 139, I-LCID 142). ES inbound port set lookup 202 can be constructed by search of inbound port route database 182, which is stored in stored in ES memory 119.

As shown in Fig. 12B, ES outbound port lookup 204 takes two inputs (ESOI-ID 147, O-LCID 148). It returns a single pair (ESID 152, LPID 154). ES inbound port set lookup 204 can be constructed by search of inbound port route database 194, which is stored in stored in ES memory 119.

ES Packet classification As shown in Fig. 12C, ES classification lookup 206 takes two inputs (ingress external data packet 106 and LPID 154). It provides a the means to inspect the input parameters, return a route (ESII-ID 139, I-LCID 142) to CS 118, and create an internal data segment derived from the packet. The details of ES classification lookup 206 are not specified here, as many techniques are available.

ES classification lookup 206 may drop a packet by not returning a result.

Method of Inbound Operation and Remote Port Identification

Fig. 13 provides an illustration of packet ingress and inbound segment transfer. For details, refer to Fig. 14 for the sequence steps of inbound and Remote Port Identification operation 212. The process starts at step 1400 as port 104 of end station 116 receives an ingress external data packet 106. The GPID 156 of this particular port of ingress is ingress GPID (I-GPID) 157. In step 1402, the content of packet 106 is transferred to packet processor 150, along with LPID 156 identifying the delivery port 106.

In step 1404, packet processor 150 submits said ingress external data packet 106 as well as LPID 156 to ES classification lookup 206, which in step 1406 returns inbound internal data segment 134 based on the content of the ingress external data packet 106 as well as the port of arrival LPID 156, returning as well the inbound route (ESII-ID 139, I-LCID 142) for transmission to the CS.

Packet processor 150 sends (step 1408) inbound link logical connection identifier I-LCID 142, as returned from the step 1406, and inbound internal data segment 134 to the ES inbound link internal interface 138 associated with the returned value of ESII-ID 139. In step 1410, ESII-ID

139 transfers inbound internal data segment 134 to CS 118 on logical connection I-LCID 142.

At step 1412, inbound internal data segment 134 and accompanying I-LCID 142 are received at

CS inbound link internal interface 140 designated by CSII-ID 141 , which passes them in step 1414 to segment processor 151 , along with two other elements of data: the I-LCID 142 as received, and CSII-ID 141 identifying the link internal interface 140 at which said segment was received.

Segment processor 151 , in step 1416, passes CSII-ID 141 and I-LCID 142 to CS inbound port lookup 196, which, in step 1418 returns ESID 152 and LPID 154 in step 1418. This pair represents I-GPID 157 identifying the original incident port 104. Remote Port Identification is then complete.

In step 1420, segment processor 151 passes inbound internal data segment 134 and I-GPID 157 to core forwarding engine 110. Inbound operation 212 concludes at step 1422.

Core forwarding

Steps of the core forwarding operation 214 are shown in Fig. 15.

In step 1500, core forwarding engine 110 begins processing inbound internal data segment 134 and I-GPID 157, which it received during step 1416 of operation 212 (Fig. 14).

In step 1502, core forwarding engine 110, consulting with core forwarding database 112 (stored in CS memory 119) and using methods such as those familiar to practitioners, selects one or more GPIDs 156 to which to forward inbound internal data segment 134. Because core forwarding engine 110 knows the ingress port identifier I-GPID 157, it is enabled to apply switch learning methods, VPN methods, SDN methods, etc.

In step 1504, core forwarding engine 110 creates forwarding data segment 137 to carry appropriate data of inbound internal data segment 134, while adding, removing, or altering certain packet header information according to methods familiar to practitioners.

In step 1506, core forwarding engine 110 transfers forwarding data segment 137, I-GPID 157, and said selected E-GPIDs 159 to segment processor 151 , achieving Remote Port Identification.

In step 1508, core forwarding engine 110 updates core forwarding database 112 (stored in CS memory 119) with port learning information, using methods familiar to practitioners.

Core forwarding operation 214 concludes at step 1510.

Method of Outbound Operation and Remote Forwarding Control

Fig. 16 provides an illustration of outbound and egress operation. For details, refer to Fig. 17 for the sequence steps of outbound operation and Remote Forwarding Control 216.

In step 1700, segment processor 151 begins with forwarding data segment 137, I-GPID 157, and said selected E-GPIDs 159, which it received during step 1506 of operation 212 (Fig. 15). In one embodiment, outbound operation and Remote Forwarding Control 216 is conducted for the set of selected E-GPIDs 159. Here we describe the operation with respect to a single E-GPID 159. In other embodiments, segment processor 151 may arrange multicast or broadcast delivery when multiple E-GPIDs 159 are provided. Multicast within the ports 104 of a single ES 116 is addressed in step 1716 of this procedure.

In step 1702, segment processor 151 submits forwarding data segment 137, 1-GPID 157, and E- GPID 159 to CS segment classification 200, which classifies the packet based on the content of the packet as well as the ingress port of arrival I-GPID 157 and the ingress port of delivery E- GPID 159.

In step 1704, CS segment classification 200 returns outbound internal data segment 136, to carry appropriate data of forwarding data segment 137, while adding, removing, or altering certain packet header information according to methods familiar to practitioners. CS segment classification 200 also returns the outbound route (CSOI-ID 145, O-LCID 148).

In step 1706, segment processor 151 sends outbound internal data segment 136, CSOI-ID 145, O-LCID 148 to the interface CSOI-ID 145. In step 1708, CS outbound link internal interface 144 at CSOI-ID 145 transmits outbound internal data segment 136 and O-LCID 148 via outbound link 132 to ES outbound link internal interface 146 designated ESOI-ID 147.

In step 1710, the interface ESOI-ID 147 transfers outbound internal data segment 136 and O- LCID 148 to packet processor 150, along with the value ESOI-ID 147. In step 1712, packet processor 150 passes O-LCID 148 to ES outbound port lookup 204, which returns LPID 154 in step 1714.

In step 1716, packet processor 150 transfer outbound internal data segment 136 to all local ports 104 affiliated with scalar LPID 154 entries in the returned compound field LPID 154. For unicast delivery, a single such value of LPID 154 will be included in the compound field. If the packet is not intended for delivery at the particular ES receiving it, no match will be found and no action is ordered.

In step 1718, the ports 104 at LPID 154 send outbound internal data segment 136 for egress. The procedure closes at step 1720.

By these methods and systems, said port extension system 128 provides Remote Forwarding Control and Remote Port Identification enabling port learning. Other embodiments

Like the methods of Remote Port Identification and Remote Forwarding Control, other embodiments of this disclosure apply similar concepts related to communication with a plurality of connections available. For example, Remote Port Identification binds outgoing connections to routes, binds routes to ports, provides receivers with the bindings, enables receiving stations to discern the connection of incoming packets, enables the information exchanges, and links all the steps. With these elements in place, the receiving station can discern the port of access, and the transmitting. Remote Forwarding Control embodies the disclosure differently, binding incoming rather than outgoing connections to routes. As a result, the sending station can choose the route, and the method and system deliver the packet to a preferred port. In both of those embodiments, the packet delivery brings information about the packet; in one case, that information relates to the source of the packet; in another, it relates to the destination.

As can be plainly seen, connection identifiers and routes play a role in remote Remote Port Identification and Remote Forwarding Control. In order for both of these processes to perform properly in a single system, routes must be specified differently in the two directions of transport because the endpoints are not identical in the two cases.

Other embodiments of the disclosure apply different bindings. In general, by binding connections to an attribute of the packet, the packet can inherently deliver information regarding the attribute. Remote Port Identification and Remote Forwarding Control deliver information about the originating port and the intended ports of arrival. Many conventional point-to- multipoint networks bind logical connections to an end station because, in those cases, links are shared by a plurality of end stations. However, such networks can be deployed with alternative bindings, as methods disclosed here demonstrate in the case in which the ports in the binding are all accessible through the same end station. In that treelike scenario, a route to the port of an end station incorporates routing to the end station. The end station can thus be enabled to decide whether to forward a packet based not on whether the packet is intended for the end station but instead based on whether the packet is intended for one of the end station's ports.

Other embodiments of the disclosure accommodate additional layers of routing beyond that enabled in Remote Port Identification and Remote Forwarding Control. The flowchart in Fig. 18 demonstrates procedure for communicating a binary- valued parameter associated with a packet of data 218. The particular illustrative embodiment addresses the scenario in which a plurality of connections is provided, each of these supporting transmission of data from a transmitter to a receiver such that the receiver can identify the connection upon receipt of the data, a subset of such connections is identified, the use of the selected connections is restricted to packets for which the binary- valued parameter is true, and a receiver has been supplied with a list of identifiers of connections belonging to the selected subset. The sequence of steps is shown in Fig. 18. In step 1802, the transmitter transmits the packet of data on one of the connections. In step 1804, the data traverses the connection. In step 1806, the receiver receives the data and the identifier of the connection of receipt. In step 1808, the receiver compares the identifier of the connection of receipt to the supplied list of identifiers of connections. In step 1810, the receive decides whether identifier of the connection of receipt belong to the supplied list of identifiers of connections. If yes, the process proceeds to step 1812, with the parameter being determined to be true; in that case, the process then ends at step 1814. If no, then the process proceeds to step 1816, with the parameter being determined to be false; in that case, the process then ends at step 1818.

REFERENCE SIGNS LIST

The following is a listing of elements referred to in the Application and Figures and their reference numbers:

102 packet switch 104 port

106 ingress external data packet

108 egress external data packet

110 core forwarding engine

112 core forwarding database 114 extended packet switch network

116 end station (ES)

117 ES memory

118 core station (CS)

119 CS memory 120 backhaul interconnection

128 port extension system

130 inbound link

132 outbound link

134 inbound internal data segment 136 outbound internal data segment

137 forwarding data segment

138 ES inbound link internal interface

139 ES inbound interface identifier (ESII-ID) 140 CS inbound link internal interface

141 CS inbound interface identifier (CSII-ID)

142 inbound link logical connection identifier (I-LCID) 144 CS outbound link internal interface

145 CS outbound interface identifier (CSOI-ID)

146 ES outbound link internal interface

147 ES outbound interface identifier (ESOI-ID)

148 outbound link logical connection identifier (O-LCID)

149 end station ID database (ESID database)

150 packet processor

151 segment proces sor

152 end station identifier (ESID)

153 ESID lookup

154 local port identifier (LPID)

156 global port identifier (GPID)

157 ingress GPID (I-GPID)

158 port lookup

159 egress GPID (E-GPID)

160 ESII lookup

162 ESOI lookup

164 I-LCID lookup

166 O-LCID lookup 168 inbound interface lookup

170 outbound interface lookup

172 inbound route database population procedure

174 inbound route database

176 outbound route database population procedure

178 outbound route database

180 inbound port route configuration procedure

181 inbound port assignment configuration table 181

182 inbound port route database

184 outbound port route configuration procedure

185 outbound port assignment configuration table 185

186 outbound port route database

188 ES ingress port route database establishment procedure

190 ES ingress port route database

192 ES egress port route database establishment procedure

194 ES egress port route database

196 CS inbound port lookup

198 CS outbound port set lookup

200 CS segment classification

202 ES inbound port set lookup

204 ES outbound port lookup

206 ES classification lookup 212 inbound and Remote Port Identification operation

214 core forwarding operation

216 outbound operation and Remote Forwarding Control

218 procedure for communicating a binary- valued parameter associated with a packet of data

REFERENCES CITED

PATENT DOCUMENTS

US20060029072

US8396053 US20130191257

US7633937

EP2547047A1

US20050053079

US20120106566 US20120233350

US8144715

US20060190570

US8599842

US6954810 OTHER PUBLICATIONS

Marks, R.B., "Integration of IEEE 802.16 and Carrier Ethernet," IEEE 802.16-13-0049-01-OOOr, 12 March 2013. Marks, R.B., "Bridging Issues in Integration of IEEE 802.16 and Carrier Ethernet," IEEE 802.16-13-0057-00-OOOr, 18 March 2013.

Marks, R.B., "Integration of IEEE 802.16 with OpenFlow Software-Defined Networking," IEEE IEEE 802.16-13-0084-04-000r, 11 May 2013.

Marks, R.B., "Connection-Oriented Software-Defined Networking," IEEE 802.16-13-0098-01- OOOr, 11 May 2013.

Marks, R.B., "View of Connection-Oriented Software-Defined Networking for Wireless Backhaul of Small Cells," IEEE 802.16-13-0151-00-OOOr, 18 July 2013.

Claims

CLAIMS WHAT IS CLAIMED IS:

1. A method of communicating binary-valued parameters associated with respective packets of data, comprising: providing a plurality of connections; selecting a subset of said connections; restricting the use of said selected connections to packets for which said parameter has a value of TRUE; supplying a receiver with a list of identifiers of members of said subset; transmitting said packet on one of said connections; receiving data of said packet at said receiver; receiving said identifier of said connection on which said packet was transmitted; determining whether said received identifier is a member of said list and: if so, concluding that said parameter has a value of TRUE; otherwise, concluding that said parameter has a value of FALSE.

2. The method of Claim 1 in which said parameter represents neither whether or not the packet was transmitted by a specific transmitter nor whether or not it is intended for a specific receiver.

3. The method of Claim 2 in which said parameter represents whether data of said packet had previously entered a particular port.

4. The method of Claim 2 in which said parameter represents whether or not said packet should be forwarded to a particular port or plurality of ports upon reception.

5. The method of Claim 2 in which said connections are differentiated by logical properties.

6. The method of Claim 2 in which said connections are differentiated by both logical properties and physical properties.

7. An extended packet switch, comprising: at least one end station, each said end station with at least one end station port for receiving and transmitting packets of data and with at least one internal interface, each said internal interface enabled to communicate via a link to a core station by exchanging segments of data, and a core forwarding engine, operating in such a way that data received at said core forwarding engine following its delivery at a particular ingress port among said end station ports is accompanied by a record of the identifier of said ingress port, and operating in such a way that said core forwarding engine is enabled to assign the egress ports, among said end station ports, for delivery of data.

8. The extended packet switch of claim 7 in which no tags are imposed onto said segments of data beyond those required to support the protocol of said link.

9. The extended packet switch of claim 7 in which at least one end station includes a plurality of egress ports and transmits a packet of data to a subset of such egress ports based on assignment by the core forwarding engine of said egress ports to said packet of data.

10. The extended packet switch of claim 9 in which at least one said link is shared among said end stations.

11. The extended packet switch of claim 9 in which data are carried on a plurality of inbound physical connections or outbound physical connections.

12. The extended packet switch of claim 9 in which at least one said link uses a wireless communication method.

13. The extended packet switch of claim 9 in which decisions at said core forwarding engine are informed by software-defined network methods.

14. The extended packet switch of claim 9 in which data on at least one said inbound physical connection is used by only a single end station.

15. The extended packet switch of claim 9 in which data from a set of said segments of data is delivered to the same egress port after transit over different outbound physical connections or over different virtual connections.

16. The extended packet switch of claim 15 in which the selection of said physical connections used to deliver said segments of data is configurable to vary depending on said ingress port of said packet of data or on said egress port of said packet of data.

17. The extended packet switch of claim 9 in which packets of data formatted as Ethernet frames with VLAN tags are switched transparently.

18. A method of operating a packet switch network with end stations enabled to receive and transmit packets using at least one end station port, comprising: providing a core station; providing a plurality of inbound connections, each said inbound connection supporting transmission of data from one said end station to said core station such that said core station is enabled to identify said inbound connection upon receipt of said data; assigning a connection for use only in transmitting data received at a particular ingress port among end station ports; receiving an ingress data packet at an end station's ingress port; transmitting a data segment including content from said ingress data packet to said core station; and presenting said data segment to a core forwarding engine at said core station along with a designator of the ingress port.

19. The method Claim 18, further comprising: providing a plurality of outbound links, each of which enables transmission of outbound data segments to at least one said end station; providing outbound connections, each said outbound connection supporting transmission of data from said core station to at least one said end station, such that said end station is enabled to identify said outbound connection upon receipt of said data; assigning a connection for use only in transmitting data intended for delivery to at least one particular egress port among end station ports; transmitting a data segment; receiving said data segment by at least one said end station; identifying said outbound connection on which said data segment was received; and forwarding said data segment to zero or more ports of said end station based on said identified outbound connection.

20. The method Claim 19 in which at least one said outbound link enables transmission of outbound data segments to a plurality of said end stations.