IN NETWORKS THAT UTILIZE SEGMENT ROUTING

BACKGROUND

[0001] Mobile communications continue to evolve. A fifth generation may be referred to as 5G.

SUMMARY

[0002] Systems, methods, and instrumentalities are disclosed for mitigating cyclic redundancy check (CRC) value calculations in networks that utilize segment routing (SR). CRC value calculations may be mitigated at some or all intermediate destinations in an SR path.

[0003] For example, CRC calculation may be mitigated at some or all intermediate switches in an SR path in a cut-through network. A CRC may be calculated on a frame as the frame may be received by a final destination switch in an SR path with intermediate switches.

[0004] In an example of a mixed network (e.g. , a network including cut-through switches and store-and-forward (SnF) switches), CRC recalculation may be selectively applied according to rules that may specify which intermediate switches may recalculate CRC and to which switch in the SR path the CRC may be recalculated.

[0005] In an (e.g., another) example of a mixed network, CRC values may be pre-calculated by a switch building an SR path. CRCs may be pre-calculated for selected (e.g., one or more) or all intermediate switches specified in an SR path to mitigate CRC re-calculation at some or all intermediate switches. A number (e.g. , a minimal number) of CRCs may be pre-calculated according to rules. CRCs for some or all intermediate switches specified in an SR path may be pre-calculated without rules. A switch (e.g., each switch) with a pre-calculated CRC value in a list of CRC values appended to a frame may drop (e.g. , not forward) its pre-calculated CRC value.

[0006] A pre-calculated CRC may be removed at an intermediate cut-through switch while preserving cut-through forwarding of bytes as soon as they are received, for example, based on frame length (when specified) or based on an offset between ingress reception and egress transmission and inter-packet gap detection.

[0007] A switch may include a processor configured to receive a frame comprising a segment list comprising an address associated with a switch in a segment routing (SR) path. The switch may read a portion of the frame to determine if the segment list comprises an address associated with another switch in the SR path. If the segment list comprises an address associated with another switch in the SR path, the segment list may be modified. If not, the frame may be forwarded in a cut-through mode at least by forwarding the frame without recalculating a cyclic redundancy check (CRC) value.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented.

[0009] FIG. IB is a system diagram of an example WTRU that may be used within the communications system illustrated in FIG. 1 A.

[0010] FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A.

[0011] FIG. ID is a system diagram of another example radio access network and another example core network that may be used within the communications system illustrated in FIG. 1 A.

[0012] FIG. IE is a system diagram of another example radio access network and another example core network that may be used within the communications system illustrated in FIG. 1 A.

[0013] FIG. 2 illustrates an example of a problem with segment routing leading to CRC recalculation in cut-through networks.

[0014] FIG. 3 illustrates an example of a frame format with segment routing support.

[0015] FIG. 4 illustrates an example of a frame format when using SR in an MPLS domain.

[0016] FIG. 5 illustrates an example of SR using MAC-in-MAC Frame Format.

[0017] FIG. 6 illustrates an example of implementing SR in a cut-through network environment.

[0018] FIG. 7 illustrates an example of implementing SR in a mixed network environment with selective CRC recalculation.

[0019] FIG. 8 illustrates an example of implementing SR in a mixed network environment with pre-calculated CRCs for selected destinations. [0020] FIG. 9 illustrates an example of implementing SR in a mixed network environment with pre-calculated CRCs for some or all specified destinations.

[0021] FIG. 10 illustrates an example of supporting pre-calculated CRCs for cut-through forwarding.

DETAILED DESCRIPTION

[0022] A detailed description of illustrative embodiments will now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

[0023] FIG. 1A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- carrier FDMA (SC-FDMA), and the like.

[0024] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs), e.g., WTRUs, 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0025] The communications system 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0026] The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in some embodiments, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0027] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 115/116/117 may be established using any suitable radio access technology (RAT).

[0028] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA).

WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0029] In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE- A).

[0030] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0031] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In some embodiments, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular- based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106/107/109.

[0032] The RAN 103/104/105 may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1 A, it will be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, the core network

106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0033] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.

[0034] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0035] FIG. IB is a system diagram of an example WTRU 102. As shown in FIG. IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB or HeNodeB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. IB and described herein.

[0036] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller,

Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0037] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 115/116/117. For example, in some embodiments, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0038] In addition, although the transmit/receive element 122 is depicted in FIG. IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in some embodiments, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.

[0039] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0040] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown). [0041] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0042] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination implementation while remaining consistent with an embodiment.

[0043] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0044] FIG. 1C is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 1C, the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0045] As shown in FIG. 1C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0046] The core network 106 shown in FIG. 1C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0047] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0048] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0049] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0050] FIG. ID is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0051] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In some embodiments, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. [0052] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink (UL) and/or downlink (DL), and the like. As shown in FIG. ID, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0053] The core network 107 shown in FIG. ID may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0054] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an SI interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer

activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0055] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0056] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0057] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0058] FIG. IE is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 117. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0059] As shown in FIG. IE, the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In some embodiments, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0060] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication,

authorization, IP host configuration management, and/or mobility management.

[0061] The communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c. [0062] As shown in FIG. IE, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0063] The MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0064] Although not shown in FIG. IE, RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0065] Systems, methods, and instrumentalities are disclosed for mitigating CRC calculations in networks that utilize segment routing (SR). CRC calculations may be mitigated at some or all intermediate destinations in an SR path.

[0066] For example, CRC calculation may be mitigated at some or all intermediate switches in an SR path in a cut-through network. A CRC may be calculated on a frame as it may be received by a final destination switch in an SR path with intermediate switches. [0067] A switch may refer to a computer networking device that is configured to connect devices together on a computer network. For example, the switch may use packet switching to receive, process, and/or forward data to the destination device. A switch may be configured to forward data to one or multiple devices (or other switches) that are destinations or in the destination path for the data (e.g., while refraining from forwarding to other devices that are not the destination/in the destination path), for example rather than broadcasting the data out of each of its ports. A switch may also be referred to as a network switch, a switching hub, a bridging hub, a MAC bridge, etc. A switch may be a multiport network bridge that uses hardware addresses to process and forward data at the data link layer. Some switches may process data at the network layer (e.g. , layer 3) by incorporating routing functionality, for example, using IP addresses to perform packet forwarding (e.g. , such switches may be referred to as layer-3 switches or multilayer switches).

[0068] A store-and-forward (SnF) switch may buffer and/or verify frame(s) before forwarding the frame towards the frame destination. The frame may be received in its entirety before the frame is forwarded by an SnF switch. A cut-through switch may begin forwarding a frame after the frame's destination address is received (e.g., rather than waiting for the entire frame to be received). A cut-through switch may be configured to fall back to store-and-forward operation, for example when the outgoing port is busy at the time the destination address becomes available.

[0069] A switch may be implemented in a core network of a cellular network provider. For example, the switch may be implemented in a 4G and/or 5G core network. The switch may facilitate control-plane and/or data-place frame forwarding and/or routing.

[0070] In an example of a mixed network (e.g. , a network including cut-through switches and SnF switches), CRC recalculation may be selectively applied according to rules specifying which intermediate switches may recalculate CRC and to which switch in the SR path the CRC may be recalculated.

[0071] In an (e.g., another) example of a mixed network, CRCs may be pre-calculated by a switch building an SR path. CRCs may be pre-calculated for selected (e.g. , one or more) or all intermediate switches specified in an SR path to mitigate CRC re-calculation at some or all intermediate switches. A number (e.g. , a minimal number) of CRCs may be pre-calculated according to rules. CRCs for some or all intermediate switches specified in an SR path may be pre-calculated without rules. Each switch with a pre-calculated CRC in a list of CRCs appended to a frame may drop (e.g. , not forward) its pre-calculated CRC. [0072] A pre-calculated CRC may be removed at an intermediate cut-through switch while preserving cut-through forwarding of bytes as soon as they are received, for example, based on frame length (when specified) or based on an offset between ingress reception and egress transmission and inter-packet gap detection.

[0073] Cut-through switches may be enabled and used for transport packet formats that may employ segments or labels to assist with their routing (e.g. , switching). Cut-through switches may not (e.g., may not be intended) to look into packet data and may not be capable of performing CRC calculations. Mitigation may be provided for Cyclic Redundancy Check (CRC) calculations that may be required at (e.g., every) change or update in segment or label information in cut-through switches. The advantage of using cut-through switches for low latency switching may be preserved while supporting segment or label information for optimization of forwarding performance across multiple domains.

[0074] Multiprotocol Label Switching (MPLS) may allow (e.g. , most) packets to be forwarded at Layer 2 (the switching level), e.g., rather than being passed up to Layer 3 (the routing level). A (e.g., each) packet may be labeled, e.g., by an ingress router, upon entry into a service provider's network. Switches performing subsequent routing may perform packet forwarding based (e.g., only) on the labels, e.g. , they may not (e.g. , may never) look as far as the IP header. An egress router may remove the label or labels and may forward the original IP packet toward its final destination.

[0075] A label may determine which pre-determined path a packet may follow. Paths may allow service providers to decide, e.g. , ahead of time, the (e.g., best) way for (e.g. , certain types of) traffic to flow within a private or public network.

[0076] Segment routing (SR) is a type of forwarding that may leverage and/or extend source routing. A source may define the path that a packet may (e.g., will) take.

[0077] Segment routing may be instantiated in many ways by different protocols. For example, a segment may be a label in a MPLS domain. For example, segment routing may be used to attempt to simplify MPLS networks. Segment routing may facilitate interfacing with software-defined networks and/or allow for source-based routing. Segment routing may be performed without having to keep state information in the core of the network. As an example, segment routing may use MPLS to forward the packets, but the labels may carried by an Interior Gateway Protocol (IGP). In segment routing, nodes may be associated with unique identifier, which may be referred to as a segment identified. Use of segment routing may enable the source device (e.g., an application controller) to steer traffic over different paths, for example, depending on different transmission requirements and the current state of the network. [0078] An ordered list of segments may be encoded, e.g., as a stack of labels, for example, when using MPLS, or as an ordered list of IPv6/IPv4 addresses, MAC addresses or any address type that may be used for forwarding in the network.

[0079] A network may use intelligence (e.g., Software-Defined Networking (SDN) or another type of intelligence), for example, to decide what segment identifiers to use.

[0080] Store and forward may be a telecommunications technique in which information may be sent to an intermediate station where it may be kept and may be sent (e.g., at a later time) to a final destination or to another intermediate station. An intermediate station or node in a networking context may verify the integrity of a message before forwarding it.

[0081] In an example of computer networking, cut-through switching may be an operation or method for packet switching systems where a switch may start forwarding a frame or packet before the whole frame has been received. In an example, a switch may start forwarding a frame or packet as soon as the destination address is processed. Cut-through switching (e.g., compared to store-and-forward) may reduce latency through a switch and may rely on destination devices for error handling.

[0082] 5G transport networks may provide low-latency /high-throughput, for example, to support 5G fronthaul and backhaul traffic. Cut-through switching may enable low-latency and may be implemented in 5G transport networks. For example, cut-through switch may be utilized in 5G core networks.

[0083] 5G transport networks may provide a high degree of flexibility and adaptability, for example, to support various levels of traffic types, support a wide range of 5G Points of Access (e.g., macro-cells, small-cells, hotspots, remote radio heads, C-RAN baseband units and mobile- edge computing nodes) and/or support network slicing.

[0084] Support for low latency and high throughput for fronthaul traffic in a 5G network may be provided, for example, by cut-through switches. Segment Routing may simplify traffic routing and management. Segment routing may interface with software-defined networks (SDNs) and may support source-based routing.

[0085] Combining cut-through switches and segment routing may be difficult, for example, given that frames may be subject to a pre-defined list of modifications along a path. A CRC may be recalculated after a modification. For example, a whole frame may (e.g. , must) be captured before adjusting or calculating a CRC. Cut-through forwarding may be eliminated when switches (e.g. , must) act according to store and forward.

[0086] An intermediate switch specified as the destination in a frame may remove its own identifier and may ensure that the destination field for the frame is filled with the next segment identifier specified in the segment routing path before forwarding the frame. In an example implementation of segment routing in MPLS, an intermediate switch may remove its own label and forward the frame to the next destination (e.g., next label), for example by adding a label corresponding to the next destination. Segment routing may be applied to segment pointer update techniques (e.g., IPv6 Segment Routing - IPV6 extension header), where a switch may update the first segment index to point to the next segment in the segment list (e.g., next destination).

[0087] FIG. 2 is an example of a problem with segment routing leading to CRC recalculation in cut-through networks. CRC may be recalculated when a frame is modified, which may involve reading the entire frame/packet and eliminating the benefits of cut-through switching.

[0088] In the example shown in FIG. 2, a frame at switch A may be sent to switch E. Based on segment routing (SR), a list of intermediate destinations may be specified (e.g., B and G). A CRC may be calculated on the whole frame before sending the frame.

[0089] Switches B and G may be configured with cut-through switching, where a frame may be forwarded before the whole frame has been received, such as forwarding when the destination becomes known. However, given that switch B is specified as an intermediate destination in this routing example, the frame may be modified when switch B receives the frame to specify the next intermediate destination G, which may lead to recalculation of the CRC and loss of the benefit of cut-through switching.

[0090] Likewise, given that switch G is specified as an intermediate destination in this routing example, the frame may be modified again when switch G receives the frame to specify the next destination E, which may lead to another recalculation of the CRC before forwarding the frame to switch E and another loss of the benefit of cut-through switching.

[0091] Switch E, the final destination, may receive the frame and perform normal processing, e.g. , check frame validity (e.g. , using CRC) and propagate the frame (e.g., when valid) to an upper layer.

[0092] Segment routing (SR) may specify one or more intermediate destinations (e.g., a forwarding path) in a frame. Segment routing may be combined with cut-through forwarding (CTF), which may expedite forwarding by avoiding frame validation, for example, by optimizing and managing when and how CRC recalculation occurs. At least some (e.g., all) of the benefit of cut through routing may be maintained. Cumulative benefits of segment routing and cut-through switching may be supplemented.

[0093] In an example, a CRC may not be validated until a frame reaches its destination. CRC calculation may be performed based on receipt of the frame by the last (e.g., destination) switch, after intermediate destinations/segments placed in a frame by SR may be removed from the frame. A CRC may not be calculated when the frame is modified at intermediate switches.

[0094] In an (e.g., another) example, a network may comprise a mix of cut-through switches and store-and-forward (SnF) switches that may validate frames. Switches (e.g., all switches) may be aware of network topology and configured switching procedure(s).

[0095] In a first example, switches in or along a path performing CRC recalculation may be specified, e.g. , according to rules specifying which switches should recalculate CRC and/or rules specifying up-to which other switch the CRC should be recalculated.

[0096] In an (e.g., another) example, CRCs may be pre-calculated (e.g. , up front), for example, by a switch building an SR path. A resulting list of pre-calculated CRCs may be appended to the frame. In a first example, a number (e.g., a minimal number) of CRCs may be pre-calculated, e.g. , according to specified rules, which may avoid CRC re-calculation while forwarding a frame. Pre-calculated CRCs may be removed from the frame, e.g. , based on specified rules.

[0097] CRCs may be pre-calculated, e.g. , based on frame content received at every switch specified in the SR path. A (e.g., respective) pre-calculated CRC may be removed by each switch specified in the SR path. Switches may not need to be aware of network topology.

[0098] Pre-calculated CRCs may be efficiently removed on a cut-through switch, e.g. , based on inter-packet gap detection, which may preserve the cut-through forwarding of bytes as soon as they are received.

[0099] FIG. 3 is an example of a frame format with segment routing support. FIG. 3 shows an example SR frame format to illustrate examples. In an example, a destination segment identifier (dst-segment) may be specified at/near the beginning of a frame. The list of next destination segments may be located after (e.g. , right after) the destination segment or within the frame, e.g., before the payload. Zero or more bytes may be present before or after the list of next destination segments. A switch receiving the frame and specified as the "dst-segment" may know how to identify and possibly fetch the next "dst-segment" from that list.

[0100] A segment identifier may be represented, for example, using one or more of a label, an IP address, a MAC address, etc. A segment identifier may be unique in the network where it is used, e.g. , so that forwarding may be performed based on the destination segment value.

[0101] FIG. 4 is an example of a frame format when using SR in an MPLS domain. FIG. 4 shows an example where MPLS labels may be used as segment identifiers.

[0102] FIG. 5 is an example of Segment Routing using MAC-in-MAC Frame Format. FIG. 5 shows an example of segment routing using 802.1 ah (MAC-in-MAC) frame format. [0103] SR may be implemented in a cut-through network environment, where all switches may be configured with cut-through forwarding. A frame may be forwarded as soon as the destination is read, e.g. , the frame may not be entirely read when it is forwarded. Without adaptation (e.g., configuration), SR may interfere with cut-through operation, e.g., as previously described.

[0104] Cut-through switches may not validate frames, for example, when the cut-through switches are not specified as the destination switch. Switches may determine whether they are an intermediate or final destination of a frame, for example, by looking at the list of segments specified in the frame. An implementation may take advantage of SR while also taking advantage of cut-through. In an example, cut-through switches may be made "SR-aware" or "intermediate" versus "final" destination aware.

[0105] In an example implementation of SR in a cut-through network environment, only the final destination switch may perform frame validation. A CRC may be calculated on a frame as it may be received by a final destination switch. A list of intermediate switches may be added to the frame. The frame may be sent to the network. Transmission errors may be determined (e.g., only) at the final destination.

[0106] SR may be used as a tool for optimizing forwarding in the network (e.g., flow state, traffic engineering, etc.). Flow state may be kept (e.g. , only) at the ingress point. An "SR-aware" implementation may result in the CRC being calculated (e.g. , only) once, e.g. , by the ingress switch, and being verified (e.g. , only) once, e.g. , by the egress switch (final destination), resulting in forwarding being handled in a cut-through manner.

[0107] FIG. 6 is an example of implementing SR in a cut-through network environment. A transmission process 600 may be performed at least in part at a network entrance.

[0108] At 602, a frame may be built as it may be received at the final destination, e.g., after all intermediate destinations or segments may be removed from the frame. A CRC may be calculated and added to the frame.

[0109] At 604, a path may be calculated. An SR path may be created. The frame may be updated with the SR path. The frame may be adapted or configured to be sent to an intermediate switch. The frame, as configured, may be sent into the network.

[0110] A frame may be received at an intermediate/final destination switch. A sufficient number of bytes in the frame may be read to determine whether other segments are specified in the SR path. [0111] At 606, when other segments are specified in the SR path, the destination may be updated with the next segment. The frame may be forwarded in cut-through mode (e.g. , without reading the entire frame, without validating the frame, and/or without re-calculating the CRC).

[0112] At 608, when no other segment is specified, the final destination has been reached. The frame may be validated using the CRC.

[0113] SR may be implemented in a mixed network environment, where some switches may be configured as cut-through switches. Other switches may be configured as store-and-forward switches.

[0114] Store-and-forward (SnF) switches may read entire frames, store them in memory, and check the validity of frames based on CRCs before forwarding (e.g., valid) frames to their next destination.

[0115] In an example, CRC may be calculated based (e.g., only) on a final frame with only the final destination included. The frame may be declared invalid and may be dropped at the first SnF switch in the path. A first example implementation (e.g., to avoid invalidity/dropping) may be based on CRC recalculation at one or more (e.g. , not all) switches along a pre-determined SR path. A second example implementation may involve building a list of CRCs that may be pre- calculated while assembling an initial frame containing the SR path. Example implementations may be supported, for example, by switches being made aware of network topology and configured switching procedure(s). For example, a sequence/order of store-and-forward and cut- through switches may be known or provided for a given path.

[0116] In a first example implementation of SR in a mixed network, CRC calculation may be performed by one or more switches in an SR path. An evaluation may be performed, e.g. , to minimize CRC re-calculations along a path to improve cut-through advantages or benefits. An evaluation may identify SnF and/or cut-through switches in an SR path for a frame.

[0117] One or more rules may be applied. An initial frame may include a CRC calculated (e.g. , using the rule that first applies): on the frame as it may be received by the first intermediate destination in the SR path following an SnF switch and/or on the frame as it may be received by the first intermediate destination that is an SnF switch.

[0118] A CRC may be recalculated (e.g. , using the rule that first applies): by every switch immediately following an SnF switch and/or by SnF switches specified as intermediate destinations.

[0119] A new CRC may be calculated based on: the frame that may be received by the next switch that immediately follows a next SnF switch, the frame that may be received by the first SnF switch specified as an intermediate destination, and/or, if no other SnF switches are used in the remainder of the path, the CRC may be calculated based on the frame that may be received by the last (destination) switch specified in the SR path.

[0120] FIG. 7 illustrates an example of implementing SR in a mixed network environment with selective CRC recalculation. Example operations depicted in FIG. 7 may be based on one or more rules (e.g., examples of first, second and third rules):

[0121] An SR path may be calculated at 702. The frame may be built as it may be received by the first SnF intermediate destination switch. A CRC value may be calculated on that frame. In an example shown in FIG. 7, the CRC value may be calculated on the frame as it may be received by an intermediate destination switch, e.g. , switch 1.

[0122] The frame may be updated with the complete SR path at 704. The CRC may remain unchanged. The frame may be sent. In an example shown in FIG. 7, switch B may be the first intermediate destination.

[0123] At 706, an intermediate cut-through switch (e.g., switch B) may update the header, e.g. , to indicate the next intermediate destination (e.g., switch 1) and may forward the frame in cut-through mode without validating and without recalculating the CRC.

[0124] An SnF switch may receive a frame at 708, store it in memory, and/or check its validity based on the included CRC. In the example shown in FIG. 7, the CRC has been calculated on the frame with switch 1 specified as the destination. The frame may be determined to be valid. The next destination may be specified in the header. The CRC may be calculated on that frame. The frame may be forwarded to switch C.

[0125] At 710, the switch immediately following an SnF switch may (e.g. , according to a rule) recalculate the CRC, e.g. , in addition to updating a destination in the header based on the SR path. In the example shown in FIG. 7, switch C may immediately follow SnF switch 1. The CRC may be (e.g., per a rule) recalculated on the frame as it may be received by switch D immediately following the next SnF switch on the path. SnF switch 3 may receive the frame and may validate the CRC. The frame may be forwarded (e.g., upon determining the CRC is valid). Switch 3 may not modify the frame when switch 3 was not specified as an intermediate destination.

[0126] Switch D, which may immediately follow SnF switch 3, may recalculate the CRC per a rule at 712. Given that no other SnF switch is detected along the remaining path from switch D to switch F, the CRC may be calculated on the frame as it may be received at the last switch (e.g. , switch F) specified in the SR path, e.g., to limit the number of CRC re-calculations along the path to switch F. The frame may be updated and may be sent to the next intermediate switch E. [0127] At 714, switch E may update the header to the next destination switch F and may cut- through forward the frame without checking or recalculating the CRC. Switch F, as the final destination, may check the frame validity using the CRC.

[0128] A list of CRCs for one or more switches may be pre-calculated, e.g., while assembling the initial frame containing the SR path. CRCs may be pre-calculated by the switch building the SR path. The resulting pre-calculated CRCs may be appended to the frame.

[0129] CRCs may be validated (e.g., only) by a final destination switch and/or by intermediate SnF switches. A CRC may be pre-calculated on the frames as they may be received by the last (destination) switch, by intermediate switches immediately following an SnF switch and/or by SnF switches listed in the SR path.

[0130] Along the way through the network, the frame may be modified, for example, when reaching an intermediate destination. The frame may be updated with a next destination in the SR path.

[0131] The last CRC at the end of the frame may be removed, making the second-to-last CRC the new last CRC, for example, by intermediate SnF switches and switches immediately following an SnF switch along the specified path.

[0132] FIG. 8 illustrates an example of implementing SR in a mixed network environment with pre-calculated CRCs for selected destinations.

[0133] At 802, a frame may be built to include the path to be followed (e.g., a SR path) and a list of pre-calculated CRCs. CRCs may be pre-calculated, for example, based on the frame that may be received at specific destination switches, e.g. , in reverse order starting with the final destination. In the example shown in FIG. 8, a valid CRC for the frame that may be received at final destination switch F may be (e.g., first) calculated. The next CRC may be based on the frame that may be received at switch D, which may immediately follow SnF switch 3 in the SR path. A CRC may not be pre-calculated for switch E, for example, because switch E does not immediately follow an SnF switch. The next CRC may be based on the frame that will be received at switch C, which may immediately follow SnF switch 1 in the SR path. The last CRC to be added may be based on the frame as received at switch 1, which may be an SnF switch specified in the SR path. Switch B may receive the frame and may modify it to be sent to the next destination (e.g., switch 1). The frame may be forwarded toward the next switch (e.g., switch 1) without modifying the pre-calculated list of CRCs, e.g., because switch B is not an SnF switch specified in SR path and does not immediately follow an SnF switch.

[0134] At 804, SnF switch 1 may save the entire frame in memory and may check the frame validity using the last CRC on the list (e.g., CRC(l)). The frame may be modified, e.g., given that switch 1 is specified as an intermediate destination in the SR path. The SR path may be used to determine the next destination (switch C). The pre-calculated CRC list may be modified, e.g., to remove CRC(l).

[0135] Switch C may receive the frame at 806. The CRC may not be checked, e.g., given that switch C may not be the final destination and may be a cut-through switch. However, switch C may be aware that it immediately follows SnF switch 1. Switch C may modify the frame (e.g., as may be needed) for the next destination and may remove the last CRC(C) in the list before forwarding the frame to the next destination in the SR path.

[0136] Switch 3 may receive the frame and may check frame validity at 808. Switch 3 may forward the frame toward switch D, e.g. , without modification because switch 3 is not specified as a destination.

[0137] Switch D may receive the frame at 810. Switch D may not modify the destination header, for example, because switch D is not specified as a destination. Switch D may remove the last CRC entry (e.g. , CRC(E)), e.g. , because switch D immediately follows SnF switch 3. Switch D may forward the frame to the next destination.

[0138] At 812, switch E may receive and modify the frame, for example, because switch E is listed as a destination. The frame may be modified for the next destination and forwarded immediately. The list of pre-calculated CRCs may not be modified, for example, because switch E does not immediately follow an SnF switch. Switch F (listed as the final destination) may receive the frame and check its validity against the last CRC(F).

[0139] CRCs may be pre-calculated (e.g., by a switch building an SR path) for one or more (e.g. , all) specified destination switches. CRC pre-calculation may be performed based on the frame content as it may be received at every switch that may (e.g. , may need to) modify the frame (e.g., all switches specified in an SR path). A resulting list of pre-calculated CRCs may be appended to the frame in reverse order of frame arrival. A (e.g. , respective) pre-calculated CRC may be removed by each switch specified in the SR path. Each switch specified as an intermediate destination may also remove the last CRC in the list of pre-calculated CRCs.

[0140] Logic may be simpler for this example of pre-calculated CRCs. The same or similar logic may be applied to SnF and cut-through switches in a mixed network for handling the pre- calculated list of CRCs. Switches need not be aware of network topology and there may not need to be determinations about which switches may re-calculate the CRC or to which switch they may recalculate.

[0141] FIG. 9 illustrates an example of implementing SR in a mixed network environment with pre-calculated CRCs for some or all specified destinations. [0142] At 902, a frame may be built to include a path to be followed (e.g. , a SR path) and a list of pre-calculated CRCs. Each CRC in the list may be pre-calculated, for example, based on the frame that may be received at a switch specified as a destination in the SR path, e.g. , starting with the final destination. In the example shown in FIG. 9, a valid CRC for the frame that may be received at switch F may be (e.g. , first) calculated. The next CRC in the list may be based on the frame that will be received at the preceding intermediate destination (e.g. , switch E), and so on. The last CRC to be added to the CRC list may be based on the frame to be received at switch B, which may be the first intermediate destination specified in the SR path.

[0143] Switch B may receive the frame and may modify it to be sent to the next destination (e.g. , switch 1) at 904. The last CRC in the list may be removed (e.g. , not forwarded to the next destination), for example, because switch B is specified as a destination in the SR path. The frame may be forwarded toward the next switch (e.g., switch 1).

[0144] At 906, switch 1 (an SnF switch) may save the entire frame in memory and may check the frame validity using the last CRC on the list (e.g., CRC(l)). Switch 1 may modify the frame for the next destination and may remove the last CRC in the list. The frame may be forwarded toward the next switch (e.g. , switch C).

[0145] Switch C may receive the frame at 908. Switch C (an intermediate cut-through switch) may not check the CRC. Switch C may modify the frame as needed for the next destination, may drop the last CRC(C), and may forward the frame to the next destination.

[0146] Switch 3 may receive the frame and may check frame validity at 910. Switch 3 may forward the frame without modification toward switch D, e.g. , because switch 3 is not specified as a destination. Switch D may receive the frame and may not validate it, e.g. , because switch D is a cut-through switch. The frame may not be modified, e.g. , because switch D is not an intermediate destination (e.g. , switch D may not be in the SR path). The frame may be forwarded, unmodified, to the next destination.

[0147] At 912, switch E (a cut-through switch) may receive the frame and may not check frame validity. The frame may be modified for the next destination. The frame may be forwarded, and the last CRC(E) may be dropped. Switch F may receive the frame. Switch F may check the frame validity against the last CRC(F), e.g. , because switch F is identified as the final destination.

[0148] Pre-calculated CRC handling may be performed on cut-through switches, for example, by applying cut-through forwarding. For example, bytes may be forwarded as soon as they are received without storing them in memory. A capability may be provided to cut-through switches to drop (e.g. , remove and/or decline to forward) the last CRC. A capability may provide, for example, that a cut-through switch may not forward the last four bytes that may represent the last CRC.

[0149] A frame length may be specified in the frame itself or may be known in some other way (e.g., fixed length frames). A switch may calculate the number of bytes received and may forward them as soon as they are received, e.g. , except for the bytes used for the last CRC, which may be dropped.

[0150] A frame length may not be specified in the frame or may not be known by a switch. A capability of dropping the last CRC may be implemented, for example, by providing an offset between egress transmission and ingress reception to permit a cut-through switch to drop the last CRC (e.g. , its own CRC) when forwarding. A cut-through switch may read, for example, a destination MAC (e.g., six bytes) from the header before starting forwarding on the egress (e.g., there may also be a preamble, etc.). A switch may read more from the frame, e.g. , into the segment list, etc., for example, to determine the next segment. The offset may be large (e.g. , long) enough, for example, to detect the inter-packet gap end-of-frame, e.g. , to permit removal of the CRC for the current segment from the transmit buffer.

[0151] FIG. 10 illustrates an example of supporting pre-calculated CRCs for cut-through forwarding. FIG. 10 shows an example of an offset between transmission on an egress port and reception on an ingress port. FIG. 10 illustrates an example of reception of a frame on the ingress port and inter-gap detection before forwarding on the egress port. An example of frame updates is shown, e.g. , a header may be modified to point to the next destination and the last CRC may not be forwarded.

[0152] Systems, methods, and instrumentalities have been disclosed for mitigating CRC calculations in networks that utilize segment routing (SR). CRC calculations may be mitigated at some or all intermediate destinations in an SR path.

[0153] For example, CRC calculation may be mitigated at some or all intermediate switches in an SR path in a cut-through network. A CRC may be calculated on a frame as it may be received by a final destination switch in an SR path with intermediate switches.

[0154] In an example of a mixed network (e.g. , a network that may include cut-through switches and store-and-forward (SnF) switches), CRC recalculation may be selectively applied according to rules specifying which intermediate switches recalculate CRC and to which switch in the SR path the CRC is recalculated.

[0155] In an (e.g., another) example of a mixed network, CRCs may be pre-calculated by a switch building an SR path. CRCs may be pre-calculated for selected (e.g. , one or more) or all intermediate switches specified in an SR path to mitigate CRC re-calculation at some or all intermediate switches. A number (e.g., a minimal number) of CRCs may be pre-calculated according to rules. CRCs for some or all intermediate switches specified in an SR path may be pre-calculated without rules. Each switch with a pre-calculated CRC in a list of CRCs appended to a frame may drop (e.g. , may decline to forward) its pre-calculated CRC.

[0156] A pre-calculated CRC may be removed at an intermediate cut-through switch while preserving cut-through forwarding of bytes as soon as they are received, for example, based on frame length (when specified) or based on an offset between ingress reception and egress transmission and inter-packet gap detection.

[0157] The processes and instrumentalities described herein may apply in any combination, may apply to other wireless and/or network technologies, and/or for other services.

[0158] A WTRU may refer to an identity of the physical device, or to the user's identity such as subscription related identities, e.g., MSISDN, SIP URI, etc. WTRU may refer to application- based identities, e.g. , user names that may be used per application.

[0159] The processes described above may be implemented in a computer program, software, and/or firmware incorporated in a computer-readable medium for execution by a computer and/or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and/or wireless connections) and/or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and/or optical media such as CD-ROM disks, and/or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and/or any host computer.