WO2009081128A1 - Méthode d'adaptation pour un trafic de communication - Google Patents

Méthode d'adaptation pour un trafic de communication Download PDF

Info

Publication number
WO2009081128A1
WO2009081128A1 PCT/GB2008/004210 GB2008004210W WO2009081128A1 WO 2009081128 A1 WO2009081128 A1 WO 2009081128A1 GB 2008004210 W GB2008004210 W GB 2008004210W WO 2009081128 A1 WO2009081128 A1 WO 2009081128A1
Authority
WO
WIPO (PCT)
Prior art keywords
frame
payload
generic framing
framing procedure
gfp
Prior art date
Application number
PCT/GB2008/004210
Other languages
English (en)
Inventor
Neil Harrison
Alan Mcguire
Original Assignee
British Telecommunications Public Limited Company
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB0724936A external-priority patent/GB0724936D0/en
Priority claimed from US12/004,080 external-priority patent/US8102876B2/en
Priority claimed from GB0800572A external-priority patent/GB0800572D0/en
Priority claimed from GB0800573A external-priority patent/GB0800573D0/en
Priority claimed from GB0814056A external-priority patent/GB0814056D0/en
Application filed by British Telecommunications Public Limited Company filed Critical British Telecommunications Public Limited Company
Priority to US12/808,823 priority Critical patent/US9077560B2/en
Priority to EP08863570A priority patent/EP2232785A1/fr
Priority to CN200880122095.7A priority patent/CN101904139B/zh
Publication of WO2009081128A1 publication Critical patent/WO2009081128A1/fr

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4633Interconnection of networks using encapsulation techniques, e.g. tunneling

Definitions

  • the present invention relates to a method of forming a hierarchy of stacked GFP (Generic Framing Procedure) frames.
  • the GFP hierarchy is capable of providing an adaptation layer for the Ethernet communications protocol.
  • the GFP adaptation layer enables a variety of client traffic to be carried across a carrier Ethernet network without requiring each type of client traffic to be indicated in the Ethernet frame header.
  • the invention relates to a method of enabling GFP to be carried over GFP so as to separate out the control domains of different operators of a communications network and/or enable GFP multiplexing.
  • EP 181068 entitled “Method and Device for Generic Framing Procedure Encapsulation” describes how a plurality of protocol data units (PDUs) can be cascaded into a cascaded packet which is then encapsulated in a GFP frame.
  • a device for GFP encapsulation is also described which comprises a cascading module for cascading a plurality of PDUs to form a cascade packet and a GFP encapsulation module for encapsulating the cascade packet to obtain a GFP packet.
  • the technique proposed by EP 181068 increases the occupation rate of the payload in a single GFP frame to improve transmission efficiency.
  • Multi-protocol label switching PDUs can be transmitted by adding a pending MPLS PDU to the payload information area (PIA) of a GFP data frame; transmitting the GFP data frame to the destination node via a transmission network, and retrieving the MPLS PDU from the PIA field of the GFP data frame at the destination node.
  • PIA payload information area
  • One aspect of the invention seeks to provide a method of adapting client data for transportation in a communications system, the method comprising: receiving a client frame conforming to a generic framing procedure communications protocol; and mapping the client frame to the payload area of one or more carrier frames, each carrier frame conforming to a generic framing procedure communications protocol.
  • the carrier generic framing procedure frames may be mapped to the payload area of a protocol data unit of the communications protocol used by a carrier network of said communications system.
  • the carrier network communications protocol may comprise an Ethernet communications protocol.
  • the carrier network communications protocol comprises an MPLS communications protocol.
  • a generic framing procedure frame may comprise a header having an extension field arranged to indicate the fragmentation status of its payload and the sequence number of a payload fragment.
  • a generic framing procedure frame may comprise a header having an extension field arranged to indicate a channel identity of its payload.
  • Another aspect of the invention seeks to provide a method of adapting client data for transportation in a communications system, the method comprising: receiving a client frame conforming to a generic framing procedure communications protocol; mapping the client frame to the payload area of a plurality of carrier frames, each carrier frame conforming to a generic framing procedure communications protocol and having an extension field arranged to indicate the fragmentation status of its payload and the sequence number of a payload fragment.
  • a method of reassembling a client from fragmented data transported over a communications system comprising: receiving a plurality of carrier frames conforming to a generic framing procedure communications protocol; processing an extension field of a header of each of the plurality of carrier frames to determine if it indicates the fragmentation status of its payload and the sequence number of a payload fragment; if a plurality of fragments of the same client frame are detected, processing the plurality of frames to extract each payload fragment; reassembling the client frame from said payload fragments.
  • the method may be implemented on a node in the communications network arranged to provide an aggregation service to multiplex client traffic received from lower rate ports to a carrier network accessed through one or more higher rate ports of the node, the method comprising: receiving a plurality of client frames from a plurality of lower rate ports, mapping the client traffic into the payload area of one or more of said client generic framing procedure communications protocol frames; wherein when mapping each client generic framing procedure frame to the payload information area of a carrier frame, each carrier frame conforming to a generic framing procedure communications protocol has an extension field arranged to indicate the channel number of its payload, and wherein each carrier generic framing procedure frame is mapped to the payload area of a protocol data unit of the carrier network communications protocol.
  • the method may be arranged to provide an aggregation service to multiplex traffic from lower rate ports to higher rate ports, the method comprising: receiving a plurality of client frames conforming to a generic framing procedure communications protocol from a plurality of lower rate ports; mapping each client frame to the payload information area of a carrier frame, each carrier frame conforming to a generic framing procedure communications protocol and having an extension field arranged to indicate the channel number of its payload.
  • Another aspect of the invention seeks to provide a method of generating a generic framing procedure hierarchy comprising: processing a first generic framing procedure frame to determine the overall length of the generic framing procedure frame; mapping the frame into the generic framing procedure payload area of a second generic framing procedure frame at the next level of the generic framing procedure hierarchy, whereby information enabling the size of the generic framing procedure payload remaining after that frame has been extracted is captured in one or more of the fields in the header of the generic framing procedure frame into which the first frame is encapsulated.
  • the generic framing procedure header indicator may indicate whether there are more frames left in the mapping hierarchy when de-encapsulating the generic framing procedure frame stack.
  • the header indicator may provide an indicator at level N of the hierarchy that at the N-1 level there is a generic framing procedure frame to extract.
  • Another indicator in the payload header may indicate that there are no more generic framing procedure frames to extract and the hierarchy of generic framing procedure frames is terminated.
  • Another aspect of the invention seeks to provide a method of restoring client data which has been adapted for transportation in a communications system using any of the above methods, the method comprising: processing at a node in said communications system a received frame to determine if its payload comprises a frame conforming to a generic framing procedure communications protocol; and if the payload is a generic framing procedure communications protocol frame:
  • the method may further comprise: processing one or more extension fields of a header of each de-encapsulated generic framing procedure frame to determine if a channel identifier is present indicating the channel identity of the client signal from which the payload is derived.
  • the method may further comprise: processing one or more extension fields of a header of each generic framing procedure frame to determine if one or more values of said extension fields are present which indicate the fragmentation status of its payload and the sequence number of a payload fragment.
  • the method may further comprise, if a plurality of fragments of the same client frame are detected: processing the plurality of frames to extract each payload fragment; reassembling the original payload from said payload fragments.
  • Another aspect of the invention seeks to provide apparatus comprising one or more components arranged to implement steps in any of the above method aspects.
  • One aspect of the invention seeks to provide apparatus comprising: a processor arranged to process a first generic framing procedure frame to determine the overall length of the generic framing procedure frame; a mapper arranged to encapsulate the first frame into the generic framing procedure payload area of a second generic framing procedure frame at the next level of the generic framing procedure hierarchy, whereby information enabling the size of the generic framing procedure payload remaining after that frame has been extracted is captured in the header fields of the generic framing procedure frame into which the first frame is encapsulated.
  • the generic framing procedure header indicator indicates whether there are more frames left in the mapping hierarchy when de-encapsulating the generic framing procedure frame stack.
  • One aspect of the invention seeks to provide a method of generating a generic framing procedure hierarchy comprising: processing a first generic framing procedure frame to determine the overall length of the generic framing procedure frame; and mapping the frame into the generic framing procedure payload area of a second generic framing procedure frame at the next level of the generic framing procedure hierarchy, wherein information enabling the size of the generic framing procedure payload remaining after that frame has been extracted is captured in the header fields of the generic framing procedure frame into which the first frame is encapsulated.
  • the generic framing procedure header may indicate whether there are more frames left in the mapping hierarchy when de-encapsulating the generic framing procedure frame stack by providing an indicator at each level of the stack hierarchy if at the lower level of the stack there is a generic framing procedure frame to extract.
  • Another aspect of the invention seeks to provide a method of generating a generic framing procedure hierarchy comprising: processing a first generic framing procedure frame to determine the overall length of the generic framing procedure frame; mapping the frame into the generic framing procedure payload area of a second generic framing procedure frame at the next level of the generic framing procedure hierarchy, whereby information enabling the size of the generic framing procedure payload remaining after that frame has been extracted is captured in the header fields of the generic framing procedure frame into which the first frame is encapsulated, and wherein the generic framing procedure header indicator indicates whether there are more frames left in the mapping hierarchy when de-encapsulating the generic framing procedure frame stack by providing an indicator at level N of the hierarchy that at the N-1 level there is a generic framing procedure frame to extract.
  • the de-encapsulation process comprising running down the generic framing procedure frame stack.
  • another indicator in the payload header indicates that there are no more generic framing procedure frames to extract and the hierarchy of generic framing procedure frames is terminated.
  • Another aspect of the invention seeks to provide apparatus arranged to implement the method aspect, the apparatus comprising: a processor arranged to process a first generic framing procedure frame to determine the overall length of the generic framing procedure frame; a mapper arranged to encapsulate the first frame into the generic framing procedure payload area of a second generic, framing procedure frame at the next level of the generic framing procedure hierarchy,
  • the generic framing procedure header indicator indicates whether there are more frames left in the mapping hierarchy when de-encapsulating (i.e., running down) the generic framing procedure frame stack by providing an indicator at level N of the hierarchy that at the N-1 level there is a generic framing procedure frame to extract.
  • One aspect of the invention seeks to provide an adaptation layer for a carrier network service which enables a plurality of client traffic units (for example, protocol data units (PDUs) to be encapsulated ' within a single adaptation layer traffic unit, which is in turn encapsulated within the payload area (also referred to as a service data unit) of the carrier network.
  • client traffic units for example, protocol data units (PDUs)
  • PDUs protocol data units
  • a network node When a network node receives a carrier PDU, it is able to process the PDU header to determine if the payload area of the carrier protocol data unit includes an adaptation layer signal. If an adaptation layer signal according to an embodiment of the invention is present it is processed and this enables the position of each client signal PDU encapsulated within the adaptation layer signal payload. This enables an individual , client PDU to be extracted from the adaptation payload area within the carrier frame payload area without requiring any of the other client PDUs carried within the same carrier frame payload area to be extracted as well. This enables a carrier frame to carry a variety of client signals in a more versatile manner than is known in the art.
  • Figure 1 shows schematically in more detail a standard GFP frame format
  • Figure 2A shows schematically the hierarchical levels of a GFP frame stack according to an embodiment of the invention
  • Figure 2B shows schematically the hierarchical levels of a GFP frame stack shown in Figure 2A for comparison with Figure 2C;
  • Figure 2C shows schematically the hierarchical levels of a GFP frame stack where the client end of the stack includes a plurality of GFP frames according to an embodiment of the invention
  • Figure 2D shows schematically a three-level hierarchy GFP frame stack where the intermediate level and client end of the stack includes a plurality of GFP frames according to an embodiment of the invention
  • Figure 2E shows how a frame at. level N can be fragmented into a plurality of frames according to an embodiment of the invention
  • FIG. 3 shows schematically the GFP stack in more detail according to an embodiment of the invention
  • Figure 4 shows a GFP header extension field according to an embodiment of the invention which provides a data transport scheme which fragments client traffic
  • Figure 5A shows a GFP header extension field according to an embodiment of the invention which provides a data transport scheme for multiplexing GFP client traffic
  • Figure 5B shows a GFP header extension field according to an embodiment of the invention which provides a data transport scheme for multiplexing and fragmenting client traffic
  • Figure 6 shows schematically how a plurality of client GFP channels are multiplexed into a single carrier GFP data channel according to an embodiment of the invention
  • Figure 7 shows schematically how an unfragmented client GFP data frame is fragmented into a plurality of carrier GFP frames according to an embodiment of the invention
  • Figure 8A shows schematically an encapsulating node according to an embodiment of the invention
  • Figure 8B shows schematically a de-encapsulating node according to an embodiment of the invention
  • Figure 9A shows steps in a method of encapsulating client according to an embodiment of the invention.
  • Figure 9B shows steps in a method of de-encapsulating the payload of a carrier frame according to an embodiment of the invention.
  • FIG. 1 of the accompanying drawings shows a GFP frame format as known in the art, which can be modified for use as an adaptation layer according to an embodiment of the invention.
  • the GFP frame format has the features of the protocol as defined in the G.7041 standard established by the International Telecommunications Union Telecommunications standardisation sector (ITU-T), the contents of which are hereby incorporated by reference.
  • ITU-T International Telecommunications Union Telecommunications standardisation sector
  • Those of ordinary skill in the art will be aware that the GFP protocol was intended as a universal mapping mechanism for packets into TDM technologies.
  • GFP supports multiple protocols and is extensible.
  • the preferred embodiment of the invention uses frame-based GFP, but in alternative embodiments of the invention, transparent GFP (GFP-T) is used.
  • GFP-T is an extension to GFP developed to provide efficient low- latency support for high-speed WAN applications including storage area networks. Rather than handling data on a frame-by-frame (packet-by-packet) basis, GFP-T handles block-coded (e.g., 8B/10B) character streams.
  • block-coded e.g. 8B/10B
  • a hierarchical GFP mapping scheme provides an adaptation layer for an Ethernet carrier network service.
  • the hierarchical GFP mapping scheme adaptation layer enables a plurality of client signals to be carried within an Ethernet frame, as described herein-below and, for example, as described in the applicants co-pending patent application entitled "CLIENT/SERVER ADAPTATION SCHEME FOR COMMUNICATIONS TRAFFIC which claims priority inter alia from GB0724936.0, the full contents of which are hereby incorporated by reference.
  • the structure of a GFP client frame comprises a core header, a payload header, an optional extension header, and an optional payload frame check sequence (FCS).
  • FCS payload frame check sequence
  • the Core Header has a field that has an indication for the payload length which is a 2- byte (8 octet bit) field indicating how many bytes (bit octets) are in the GFP payload area. By subtracting the subsequent payload header and any optionally present payload FCS overhead from the payload area, the payload length value also indicates the size of the true client payload information.
  • the Payload Header is a variable length area and comprises two mandatory fields and optionally, some extension headers.
  • the two mandatory types of fields are the Payload type fields of which the Payload Type Most Significant Byte (MSB) and Payload Type Least Significant Byte (LSB) are shown in Figure 1 and the header error correction (HEC) fields of which the Type HEC MSB and Type HEC LSB are shown in Figure 1.
  • MSB Payload Type Most Significant Byte
  • LSB Payload Type Least Significant Byte
  • HEC header error correction
  • the Payload Type field has multiple subfields.
  • the Payload Type Identifier (PTI) identifies the type of frame and may take two values: user data frames and client management frames.
  • the Payload FCS Indicator (PFI) subfield indicates if there is a payload FCS.
  • the Extension Header Indicator (EXI) subfield indicates the type of extension header in the GFP frame. Three types of type extension headers are known in the art, a null extension header, a linear extension header for point-to-point networks, and a ring extension header for ring networks.
  • UPI User Payload Identifier
  • the UPI is set according to the transported client signal type, of which several defined values already exist for communication protocols such as Ethernet, PPP, IP, MPLS, Fibre Channel, FICON, ESCON, and Gigabit Ethernet.
  • the Payload Information Field contains the client data.
  • Two modes of client adaptation are defined for GFP as mentioned hereinabove, frame-mapped GFP and transparent- mapped GFP.
  • Frame-mapped GFP payloads consist of variable length packets and one client frame is mapped in its entirety to one GFP frame.
  • transparent mapped GFP a number of client data characters (mapped into block codes) are carried within a GFP frame.
  • a hierarchical GFP mapping is implemented using the PTI, EXI, and UPI fields according to an embodiment of the invention.
  • Figures 2A, 2B, 2C, 2D and 2E and 3 show schematically how one or more GFP frames can be mapped inside another GFP frame.
  • the mapping process is repeatable to create a hierarchy provided that at each level the mapping is always into a bigger frame in the next level of the hierarchy. If not, then a frame is fragmented into a plurality of small segments which are mapped into a plurality of frames.
  • each GFP frame is stacked within the payload of the GFP frame at a lower level of the hierarchy.
  • the payload of each GFP frame at a higher level than the first level comprises the contents of another GFP frame.
  • the lower the level of the GFP hierarchy the closer the level is to the client layer.
  • the client layer may have a higher level than GFP in the Open Systems Interconnection communications protocol stack, but in other embodiments of the invention this need not be the case.
  • a client level can comprise GFP again or Internet Protocol or Asynchronous Transfer Mode to name a few client layer communications protocols for embodiments of the invention.
  • the higher the level of the GFP hierarchy the closer the hierarchy level is to a carrier (or equivalently server) layer.
  • the highest level of frames in the GFP hierarchy will be mapped to the payload of frames in a carrier network in a 1 :1 manner, so that the payload in each of highest level frames (level N in Figure 2B) is then mapped to the payload of a frame conforming to the communications protocol of a network which is offering a carrier service to the network from which the client signals originated.
  • the carrier (equivalently server) network has a lower level of communications protocol than GFP in the OSI communications protocol stack, but this is not the case in other embodiments of the invention.
  • a carrier network may use one of the GFP, or Ethernet, or MPLS, or ATM communications protocols and variants thereof to name but a few possible carrier network transport technologies.
  • Figure 2C shows how within a single level of the GFP hierarchy it is possible to have a plurality of GFP frames concatenated together.
  • two GFP frames are placed in the payload area of a single GFP frame at a lower level of the hierarchy.
  • the level N-1 frames carry the same client signal in Figure 2C, but alternatively, the payload of some of the N-1 level frames could originate from one or more different client signals in other embodiments of the invention.
  • two or more level N-1 frames carry fragments of the same client frame (or alternatively a level N-2 frame - see Figure 2D ) in which case their headers will also include a fragmentation indicator and sequence information.
  • Figure 2D shows schematically a three level GFP hierarchy in which at level 1 four frames are concatenated together within the payload of a single frame at level 2 of the frame hierarchy.
  • the payload of each of the level 2 frames is able to have an internal data structure which is independent of the internal data structure of any other frames also mapped into the payload of the level 3 GFP frame.
  • the left-hand side level 2 frame has a payload containing four level 1 frames.
  • the right-hand side level 2 frame has no additional internal data structure apart from client data.
  • Both level 2 frames are mapped into the payload area of the level 1 GFP frame.
  • the level 1 GFP frame can then be mapped to the payload area of a carrier network PDU for transportation over a carrier network.
  • FIG. 2E shows how in an embodiment of the invention a GFP frame at any level of the GFP hierarchy is able to be fragmented into a number of GFP frames which occupy the same level of the GFP hierarchy.
  • Each GFP frame header is modified to indicate it has a fragmented payload and is provided with a sequence indicator in its extension field, as is described in more detail later herein below.
  • This enables a client signal having a large PDU or data structure to be first mapped to a GFP frame which is then fragmented into a plurality of smaller GFP frames.
  • the smaller GFP frames can then be mapped to an equal number of carrier network frames.
  • Figure 3 shows how information from one level of the GFP frame stack is carried by the GFP frame at the next level of the GFP stack.
  • the PDU Length Indicator for a GFP frame at a first level is processed to determine how may bit octets (i.e., bytes) will taken up by the encapsulated field being mapped into the GFP payload area at the next level of the hierarchy.
  • This information enables the extraction of the encapsulated protocol data unit for the client traffic signal (which in the embodiment of the invention shown in Figures 2 and 3 is another GFP frame) as it allows the size of the GFP payload remaining after that frame has been extracted to be determined during the "de-mapping" process.
  • any node receiving the signal determines if there are other GFP frames remaining in the payload area to de- epcapsulate. For example, in Figure 2C, after de-encapsulating the first level N -1 frame from the level N frame payload area, if the entire length of the level N frame payload has not been de-encapsulated, the node performing the de-encapsulation will continue to process the bit stream received on the basis that another N -1 level GFP frame is within the N level GFP payload area.
  • the Payload header information of the GFP frame encapsulating the other GFP frame indicates what is being carried and whether it is a GFP frame or something else.
  • the GFP header indicator indicates whether there are more frames left in the mapping hierarchy when de-encapsulating (i.e., running down) the GFP frame stack.
  • An indicator provided in the header of a GFP frame at level N of a frame stack hierarchy indicates that the de-encapsulation process is to be re-iterated to de-encapsulate the GFP frames from within the payload of the GFP frame that has just been de-encapsulated, i.e., that at the next level there are one or more GFP frames to extract.
  • any other indicator in the payload header indicates that there are no more GFP frames to extract and the hierarchy of GFP frames is terminated.
  • a client communications network for example, a Local Area Network or LAN
  • a carrier communications network for example, a Wide Area Network or WAN
  • the payload of the frames in the lowest level of the GFP hierarchy comprises data conforming to a communications protocol supported by the client network.
  • GFP traffic generated in a first network domain is encapsulated within GFP provided by another network domain. This enables traffic provided by a first carrier network to be carried over the network of a second carrier in a transparent manner without requiring a instance of a common control plane.
  • GFP GFP
  • GFP protocol stack isolates the proprietary fields of one network domain by carrying them at the next frame level in the GFP frame hierarchy, thus encapsulating the proprietary fields with a GFP frame payload area over the other network domain.
  • inventions of the invention enable segmentation of client frames within the carrier network as well as concatenation of a plurality of GFP frames (whether they individually carry segments from the same client frame or not providing they can be routing in common over at least part of the carrier network) within another GFP frame which can then be mapped into the carrier frame payload area.
  • embodiments of the invention provide a data transport scheme in which the payload header and/or the optional extension header are adapted to enable client frames to be carried within carrier frames and everything else can be treated in the normal manner as described in the various GFP standards, such as G.7041 for example, whose contents are incorporated herein by reference.
  • the GFP stack is arranged to enable GFP frame- by-frame multiplexing which is described in more detail hereinbelow.
  • Another embodiment of the invention uses the GFP extension header of a GFP frame to indicate segmentation or concatenation of the GFP frames carried in its the payload.
  • the term "carrier" GFP frame indicates the frame within whose payload part or all of a client GFP frame is encapsulated, the term “client” indicating the encapsulated frame or frame fragment, i.e., the relation of each frame within the frame hierarchy.
  • a frame in the middle layer is a carrier to the first layer and a client of the third layer.
  • Each GFP frame whether client or carrier conforms to the standard GFP communications protocols (e.g. GFP-T, GFP-F, and other variants) and so comprises: a core header, a payload header, a payload area, an optional extension header, and an optional payload Frame Check Sequence.
  • the "client" GFP will itself contain data derived from a client signal and the carrier GFP frame is mapped to the payload or service data unit of a PDU of a carrier network.
  • a carrier GFP frame has a payload header which is 4-64 bytes long and comprises: a 2 byte type field which is used to implement the invention, a 2 byte header error control (HEC) that ensure integrity of the type field known as the tHEC (which is used in its standard form), an optional extension header which is 0 to 58 bytes long, and an optional 2 byte header error control (HEC) that ensures that the integrity of the optional extension header and is known as the eHEC (if present this is used in a standard form).
  • HEC 2 byte header error control
  • GFP frame which is encapsulated in the payload of a GFP frame is indicated in the carrier GFP frame by the GFP type field in the payload header and/or the optional extension header.
  • the payload header supports data link management procedures specific to the client signal being carried (in other words the payload).
  • the payload headers type field is subdivided into a number of fields as follows:
  • a 3 bit payload type identifier (PTI). This identifies the type of GFP client frames. Currently the following are defined: 000 that identifies the frames as being client data (user data frames), 100 for client management frames and other values are reserved for further study.
  • a GFP client data frame is used to transport data from the client signal.
  • the GFP Client Management Frames are used to transport information associated with the management of the client signal or GFP connection.
  • a 1 bit payload FCS (frame check sequence) indicator (PFI). This indicates the presence (set to 1 ) or absence (set to 0) of the payload FCS field.
  • UPI user payload identifier
  • One embodiment of a method of transporting data sets the type field and its subfields to a set of values.
  • the client data is transported over GFP using the client data frames.
  • These frames are GFP client frames consisting of a Core Header and a Payload Area.
  • EXI Payload specific.
  • L)PI Payload specific.
  • FCS Frame Check Sequence
  • PFI Payload FCS Indicator
  • the payload Extension Header is intended to support technology specific data link headers such as virtual link identifiers, source/destination addresses, port numbers, Class of Service, extension header error control, etc.
  • the type of the extension header is determined by the content of the EXI bits.
  • a transport scheme with a two-level GFP frame hierarchy comprises a single GFP stream being supported by the encapsulating GFP. This could for example occur to allow traffic on an incoming port to be encapsulated for transport on an outgoing port in a point-to-point configuration.
  • the extension header is a linear header. It is intended for applications that are linear (i.e, point -to point) and require aggregation of the client signals using the adaptation layer.
  • This is used in embodiments of the invention to indicate GFP multiplexing in the data transport scheme, where more than one client GFP signal is supported by the encapsulating GFP.
  • a carrier GFP (level 2 frame) payload has a length limit of N octets.
  • each carrier frame payload carries M different client payload fragments with each client payload fragment comprising N/M octets. In total however, M carrier frames are still required to send each client N octets (see also Figure 7 described herein below).
  • a data transport scheme according to the invention by providing a new extension header for the carrier GFP frame.
  • the communications system is considered to be point to point and there is no multiplexing of multiple streams.
  • the data transport scheme maps a stream where some of its frames (but not necessarily all) have a larger size than the encapsulating payload area. If all the client frames are smaller, then of course this type of extension header is not required to implement the invention.
  • an EXI value needs to be defined which can be a value taken from one of the currently unused extension headers.
  • the extension header provided has a spare field and a header error check and now comprises 4 bytes of data and provides a means of identifying if an encapsulated frame has been fragmented, if it is. the first, middle or last fragment, and provides a sequence number.
  • Figure 4 shows in more detail an exemplary internal structure of such a GFP extension header according to the invention.
  • the 4 byte header field is segmented into an 8 bit extension Header Error Check Least Significant Byte (eHEC LSB) field, an 8 bit extension Header Error Check Most Significant Byte (eHEC MSB) field, a spare 8 bit extension header field, a 6 bit Sequence Number field, and two single bit fields, the E-field and the B-field.
  • the E-field and B-field shown are sufficient to indicate what is happening with the fragmentation process or in other words the fragmentation state of the payload.
  • the sequence number indicates the order of the fragments to aid their reassembly when recovered from the carrier service.
  • Figure 5a and 5b both show how a GFP-type extension header is configured in one embodiment of the invention which implements a multiplexing scheme which requires a a channel identifier to be provided.
  • the header in Figure 5a comprises a CID field or Channel ID field which is one byte long and can therefore identify 256 different communications channels between GFP
  • a spare byte is shown in the extension header which is not used but which is used in the embodiment of the invention shown in Figure 5B where the spare byte is used to support the fragmentation of client frames.
  • Embodiments of the invention use the CID field of a GFP frame to multiplex multiple GFP sessions, each session being identified by a GFP frame having a CID with a different value.
  • a GFP frame header is 8 bytes long and the payload area is approx 65000 bytes long, it is possible to have multiple GFP sessions multiplexed in an encapsulating GFP frame.
  • the maximum number of sessions which can be multiplexed in this way is 256 although in practice the number is likely to be much smaller than 256, with the practical limit on the number of sessions which can be multiplexed in this way depending on the length of the encapsulated frames being smaller than the length of the encapsulating GFP frames payload information field.
  • multiple GFP sessions can be carried in the same GFP frame. This enables client traffic to be multiplexed from lower rate ports onto a higher rate port to provide a point- to-point aggregated service.
  • Figure 6 shows in more detail how two channels of client frames are mapped to the payload of a carrier channel.
  • client frames n, n+1 , n+2, and n+3 from channel 0 are shown on the left and client frames n, n+1 , n+2, n+3 from channel 1 are shown on the right.
  • Each frame is first mapped to the payload information of a GFP frame, which together with the payload header, extension header and FCS is then mapped to the payload area of the carrier GFP frame.
  • Each client frame is mapped using an extension header such as that shown in Figure 5A or 5B, i.e., one comprising a channel identifier (CID) value which identifies the payload of the encapsulating GFP frame is associated with a particular channel.
  • CID channel identifier
  • channel 1 is mapped with a CID value which identifies the payload of the carrier GFP frame is associated with channel 1.
  • Channel 2 is similarly mapped using an extension header comprising a CID value which identifies payload associated with channel 2.
  • the CID then simply identifies what channel a frame belongs to. If the client GFP frames are smaller or equal to the than the payload information area, then an Extension header having the form shown in Figure 5A can be used. However, if not, then additional information needs to be captured as described herein above and an extension field such as that shown in Figure 5B can be used.
  • the multiplexing process used to map the client frames into payload information and then into the payload area of a stream of GFP carrier frames can be any known multiplexing process known to one of ordinary skill in the art as apparently suitable for this purpose, and similarly the demultiplexing process can be implemented using a known demultiplexing process suitably adapted for the purposes of the invention.
  • Figure 7 shows how frame fragmentation occurs.
  • an unfragmented GFP frame comprising X bytes of payload is split into a series of X/n bytes of payload fragments.
  • the invention can be used in a variety of networking scenarios.
  • one embodiment of the invention enables a data transport scheme to be implemented in a communications system comprising a single network and GFP carrier service.
  • GFP transport apparatus for example, line cards
  • the GFP framing appears only at the edge of the location, i.e., at these points, which removes the need to perform any processing within the network.
  • a data transport scheme is implemented in a communications system comprising a second GFP carrier which offers a service to the first GFP carrier.
  • a communications system comprising a second GFP carrier which offers a service to the first GFP carrier.
  • GFP-T is performed on the first and last hops and GFP-F is performed in the middle, then as there is more information being transported in each GFP-T frame (as GFP-T supports line codes that include interframe gaps and preamble and frames) than in each GFP-F frame.
  • a data transport scheme such as that shown in Figure 7 can be implemented which fragments a larger GFP-T frame into a plurality of GFP-F frames.
  • the mapping is proprietary on the 1 st and 3 rd hop in the network, then in the intermediate hoe the proprietary mapping needs to be maintained which can again be achieved using a data transport scheme according to the invention which implements GFP-in- GFP, i.e., hierarchical or fragmented GFP.
  • a communications system uses GFP as an interface to a line system which is not supported underneath by a TDM communications protocol.
  • a carrier GFP service would have GFP traffic which is processed on each hop in the communications network. All proprietary client GFP traffic is then transported transparently over the network by implementing the data transport scheme according to an embodiment of the invention.
  • Figures 8A and 8B show schematically some of the functional components required in boundary nodes 10, 22 respectively between a client network (not shown) and a carrier network (not shown) to implement an embodiment of the invention in a communications system.
  • Figures 8A and 8B have been greatly simplified. Components which a person of ordinary skill in the art would find apparent as necessary to implement an adaptation scheme according to an embodiment the invention have been omitted for clarity.
  • the components shown in the figures and described below are for exemplary purposes. In other embodiments they may be removed, combined or substituted for by functional equivalents as are known to persons of ordinary skill in the art.
  • Figure 9A shows steps in an embodiment of the invention in which a node such as that shown in Figure 8A encapsulates client signal data within a carrier frame data structure for transmission over a carrier network.
  • Figure 9B shows steps in an embodiment of the invention in which a node such as that shown in Figure 8B de-encapsulates client signal data from within a carrier frame data structure for transmission over a client network.
  • node 10 functions as a point of encapsulation for client traffic.
  • the receiver 12 of node 10 receives a client traffic signal (step 40 shown in Figure 9A).
  • Each received client traffic unit is then processed by data processor 14 to determine from its data structure if fragmentation is required (step 42).
  • the processing determines one or more characteristics of the client signal required to map the client signal into one or more GFP adaptation layer frames, for example, the type of client signal communications protocol if this is not the same for all traffic received, the size of the client signal protocol data unit (PDU) and/or SDU routing information etc.
  • PDU client signal protocol data unit
  • the entire client PDU is mapped to the payload of the GFP adaptation layer. If the total amount of client data to be mapped to each payload area of a GFP adaptation layer frame is larger than a predetermined amount, for example, an amount which in one embodiment depends on the maximum size of payload supportable by the carrier network PDU which is determined by the size of the service data unit (SDU) of the communications protocol for the carrier network, then the client signal payload is fragmented by data fragmentor 16.
  • a predetermined amount for example, an amount which in one embodiment depends on the maximum size of payload supportable by the carrier network PDU which is determined by the size of the service data unit (SDU) of the communications protocol for the carrier network
  • the client signal PDU is passed by the data processor 14 directly to the data mapper 18 for encapsulation within the payload area of a GFP frame, and a suitable GFP header is generated. If a plurality of different client signals (for example, client channels or data streams) are to be mapped to a single carrier. channel signal for transmission in the carrier network, then each GFP frame will include in its header an indication of the client channel from which its payload was derived.
  • the GFP frame encapsulating the client signal is then in turn encapsulated by the data mapper 18 either within a carrier GFP frame which is then mapped to the payload area of a PDU for a carrier network for transmission by an appropriate transmitter over the carrier network, or directly into the payload area of the carrier PDU.
  • the carrier network is Ethernet
  • the carrier Ethernet frames are only required to include a GFP Ethertype regardless of the type of communications protocol that the client signal has.
  • each client PDU payload fragment is re-structured (step 44).
  • the client payload (equivalently client SDU) is mapped along with a copy of the client frame header to the payload of a first level GFP frame and the communications protocol type of the client signal and/or sequence and/or fragmentation data is written to the extension field(s) of the header of that first level GFP frame (steps 46 and 48) in Figure 9A and as described hereinabove with reference to Figure 5B).
  • the payload length indicator of the first level GFP frame is also generated.
  • other information required to route the client signal over the carrier network is extracted for use in generating the carrier frame header information.
  • first level GFP frame carrying client traffic is to be mapped within the payload of a carrier frame
  • a plurality of first level GFP frames are mapped to the payload area of a second level GFP frame.
  • This second-level GFP frame is then mapped to the payload area of the carrier network frame by mapper 18 shown in Figure 8A.
  • the fragmentation process also enables very large client signals to be fragmented and mapped into a plurality of GFP frame payloads where each GFP frame payload is then mapped to a carrier frame payload area. In this way, a single client frame is fragmented into a plurality of carrier frames suitable for transmission over the carrier network.
  • a GFP frame hierarchy Regardless of whether a GFP frame hierarchy according to the invention has one or more levels, it is the lowest level of the GFP frame hierarchy which is mapped to the payload area of the carrier frame (step 50) by mapper 18 for transmission out over the carrier network by transmitter 20.
  • One specific embodiment of the invention uses a two-level hierarchy of GFP frames to provide an adaptation layer for a carrier Ethernet network which enables a plurality of different client signal payloads to be carried within a carrier Ethernet frame payload area. This assumes that the client signal payloads can be routed along the same path over the Ethernet carrier network so that they can be multiplexed together within the same Ethernet frame payload.
  • Each of the highest level of GFP frames within a carrier Ethernet frame is able to carry a client signal conforming to a different communications type and/or from a different client where the different client signals are able to be transported within the same Ethernet frame. This can enable more efficient transportation of small payload signals such as VoIP over Ethernet for example.
  • the client networks could use the Ethernet communications protocol.
  • the Ethernet communications protocol is a connection-oriented protocol which enables an Ethernet Wide Area Network carrier service to be provided.
  • node 22 functions as a point of encapsulation for client traffic.
  • encapsulating node 10 may also be used to provide functionality for a de-encapsulating node, for example, the same network apparatus may both encapsulate and de-encapsulate client traffic into a GFP adaptation layer into carrier traffic and vice versa.
  • receiver 24 of node 22 receives a carrier traffic signal (step 60).
  • Each frame of the received carrier signal is processed by data processor 26 to determine if its payload comprises data conforming to the GFP communications protocol (step 61 of Figure 8B).
  • the header of each carrier Ethernet frame is processed to determine if the value in the Ethertype header field indicates the payload area contains data conforming to the GFP communications protocol. If so, a GFP frame is then de-encapsulated from the carrier frame payload (step 62) by de-mapper 28.
  • the GFP frame is then processed by data processor 26 to determine from the GFP header if the GFP frame contains any channel, sequence or fragmentation indicators (step 63) and the payload is de-extracted (step 64).
  • the sequence indicator and one or more other GFP frame headers may then be processed to determine if the sequence number indicates the GFP frame contains the "nth" payload segment or "nth" client frame in a sequence of 1 to n GFP frame payloads (step 68) and if a channel indicator is present, the channel to which the client signal data was derived.
  • the payload of the de-encapsulated frame is the nth segment in a sequence of n segments. If the payload of the de-encapsulated frame is the nth segment in a sequence of n segments, then a check is performed to see if all of the other 1 to n -1 GFP frame payloads have already been received and are stored in buffer 30, if so the other n-1 payloads are retrieved from buffer 30 (or other suitable memory means) (step 70). If not all of the other frame payloads required to reassemble the original sequence or data structure have been received then the payload of the nth GFP frame is also stored (step 72) in buffer 30.
  • a check is performed to see if the nth frame has already been stored (step 66) in buffer 30, if not, the received frame is stored (step 72) in buffer 30.
  • step 70 If the payload of the nth frame has already been received, a further check is performed to see if the payloads of all n-1 frames required to restore the data sequence/structure have now been received (step 70). If so, all previously stored payloads (step 74) are retrieved. The retrieved payloads are then reassembled (step 76) by data assembler 32. If the reassembled data also forms a GFP frame, a check is performed to see if its payload data is also GFP (step 61). If so, the process re-iterates until finally the reassembled data forms a client layer PDU (step 78).
  • client traffic transmitter 34 Once a client PDU has been recovered from the carrier network signal it can be transmitted out over a client network by client traffic transmitter 34.
  • a sequence indicator is present in the extension field of the GFP header, it indicates that the node receiving that GFP frame needs to restore a predetermined sequence of GFP frame payloads to recover the original client signal integrity. This either comprises reassembling the original sequence of client signal frames which were mapped into GFP by an encapsulating node 10 or reassembling data to form another PDU (either GFP or of the client signal if the client signal was fragmented at the encapsulating node or an intermediate node).
  • the de-encapsulated contents need only to be buffered sufficiently to restore the original sequence of PDUs forming the client signal as shown by the dashed line between steps 68 and 76 in Figure 8B.
  • the data assembler restores the payload derived from that frame to the client channel from which it was derived (and if fragmented ensures that all fragments are reassembled into a client PDU which is restored to the correct client signal channel).
  • Each client channel signal is then forwarded to the transmitter 34 for onwards transmission in the appropriate manner (which may involve different communications protocols in some embodiments of the invention).
  • a client signal can be fragmented either directly into GFP or indirectly by mapping the client signal in its entirety into a GFP frame and then fragmenting the GFP frame.
  • any communications protocol which provides equivalent functionality essential to implement the claimed invention may be used whether a standard variant or not of a current standard GFP communications protocol.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)

Abstract

L'invention concerne un procédé de génération d'une hiérarchie de procédure de génération de trame générique comprenant le traitement d'une première trame de procédure de génération de trame générique pour déterminer la longueur globale de la trame de procédure de génération de trame générique, le mappage de la trame dans la zone de charge utile de procédure de génération de trame générique d'une seconde trame de procédure de génération de trame générique au niveau suivant de la hiérarchie de procédure de génération de trame générique, les informations validant la taille de la charge utile de procédure de génération de trame générique subsistant après l'extraction de cette trame étant capturées dans les champs d'en-tête de la trame de procédure de génération de trame générique dans laquelle la première trame est encapsulée, l'en-tête de procédure de génération de trame générique indiquant s'il subsiste d'autres trames dans la hiérarchie de mappage lors de la désencapsulation (c'est-à-dire, l'extraction) de la pile de trames de procédure de génération de trame générique par la fourniture d'un indicateur au niveau N de la hiérarchie indiquant qu'il y a une trame de procédure de formation de trame générique à extraire au niveau N-1.
PCT/GB2008/004210 2007-12-20 2008-12-19 Méthode d'adaptation pour un trafic de communication WO2009081128A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US12/808,823 US9077560B2 (en) 2007-12-20 2008-12-19 Adaptation scheme for communications traffic
EP08863570A EP2232785A1 (fr) 2007-12-20 2008-12-19 Méthode d'adaptation pour un trafic de communication
CN200880122095.7A CN101904139B (zh) 2007-12-20 2008-12-19 通信业务的适应方案

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
GB0724936A GB0724936D0 (en) 2007-12-20 2007-12-20 Client/server adaptation scheme for communications traffic
US12/004,080 2007-12-20
US12/004,080 US8102876B2 (en) 2007-12-20 2007-12-20 Client/server adaptation scheme for communications traffic
GB0724936.0 2007-12-20
GB0800572A GB0800572D0 (en) 2008-01-14 2008-01-14 Network interconnection apparatus
GB0800573A GB0800573D0 (en) 2008-01-14 2008-01-14 Hierarchical client/server adaptation scheme for communications traffic
GB0800572.0 2008-01-14
GB0800573.8 2008-01-14
GB0814056.8 2008-07-31
GB0814056A GB0814056D0 (en) 2008-07-31 2008-07-31 Adaptation scheme for communications traffic

Publications (1)

Publication Number Publication Date
WO2009081128A1 true WO2009081128A1 (fr) 2009-07-02

Family

ID=40473496

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/GB2008/004226 WO2009081139A1 (fr) 2007-12-20 2008-12-19 Plan d'adaptation client-serveur pour un trafic de communication
PCT/GB2008/004210 WO2009081128A1 (fr) 2007-12-20 2008-12-19 Méthode d'adaptation pour un trafic de communication

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/GB2008/004226 WO2009081139A1 (fr) 2007-12-20 2008-12-19 Plan d'adaptation client-serveur pour un trafic de communication

Country Status (3)

Country Link
EP (2) EP2232786A1 (fr)
CN (2) CN101904139B (fr)
WO (2) WO2009081139A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3166261A1 (fr) * 2015-11-09 2017-05-10 Airbus Operations GmbH Réseau pour aéronef ou engin spatial et aéronef ou engin spatial comprenant un tel réseau
US10389551B2 (en) 2015-11-09 2019-08-20 Airbus Operations Gmbh Network for an aircraft or spacecraft, an aircraft or spacecraft, and a method for configuring a network

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8102876B2 (en) 2007-12-20 2012-01-24 British Telecommunications Plc Client/server adaptation scheme for communications traffic
PL2649847T3 (pl) 2010-12-09 2017-08-31 Lantiq Deutschland Gmbh Wzmacnianie mocy w systemie komunikacyjnym
CN114827299A (zh) * 2014-11-11 2022-07-29 三星电子株式会社 发送设备、接收设备及其控制方法
US9934171B2 (en) * 2016-02-10 2018-04-03 Qualcomm Incorporated Serial communication link with optimal transfer latency
US10798223B2 (en) 2018-03-08 2020-10-06 Fungible, Inc. Reliable communications using a point to point protocol

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050053064A1 (en) * 2003-09-08 2005-03-10 Nortel Networks Limited Method and apparatus for encapsulating services for transportation over metallic physical mediums
EP1657839A1 (fr) * 2004-11-12 2006-05-17 Alcatel Procédé et dispositif permettant de transporter un signal client à travers un réseau de transport optique (OTN)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100464517C (zh) * 2003-08-08 2009-02-25 华为技术有限公司 通用帧处理封装模式中帧校验序列的识别装置及方法
IL162305A (en) * 2004-06-02 2010-06-16 Eci Telecom Ltd Method, device and system for transmitting ethernet packets

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050053064A1 (en) * 2003-09-08 2005-03-10 Nortel Networks Limited Method and apparatus for encapsulating services for transportation over metallic physical mediums
EP1657839A1 (fr) * 2004-11-12 2006-05-17 Alcatel Procédé et dispositif permettant de transporter un signal client à travers un réseau de transport optique (OTN)

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Generic framing procedure (GFP); G.7041/Y.1303 (08/05)", ITU-T STANDARD IN FORCE (I), INTERNATIONAL TELECOMMUNICATION UNION, GENEVA, CH, no. G.7041/Y.1303 (08/05, 22 August 2005 (2005-08-22), XP017404569 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3166261A1 (fr) * 2015-11-09 2017-05-10 Airbus Operations GmbH Réseau pour aéronef ou engin spatial et aéronef ou engin spatial comprenant un tel réseau
US10389551B2 (en) 2015-11-09 2019-08-20 Airbus Operations Gmbh Network for an aircraft or spacecraft, an aircraft or spacecraft, and a method for configuring a network
US10547568B2 (en) 2015-11-09 2020-01-28 Airbus Operations Gmbh Network for an aircraft or spacecraft, and an aircraft or spacecraft including such network

Also Published As

Publication number Publication date
EP2232786A1 (fr) 2010-09-29
EP2232785A1 (fr) 2010-09-29
CN101904139B (zh) 2013-09-11
CN101926131A (zh) 2010-12-22
CN101904139A (zh) 2010-12-01
WO2009081139A1 (fr) 2009-07-02

Similar Documents

Publication Publication Date Title
US9077560B2 (en) Adaptation scheme for communications traffic
AU777645B2 (en) Circuit emulation service over an internet protocol network
US8711883B2 (en) Multiple carrier compression scheme
US6331978B1 (en) Generic label encapsulation protocol for carrying label switched packets over serial links
US6944163B2 (en) 10 Gigabit ethernet mappings for a common LAN/WAN PMD interface with a simple universal physical medium dependent interface
US7782906B2 (en) Method for carrying frame relay over Ethernet
AU2004232748B2 (en) Embedded management channel for sonet path terminating equipment connectivity
US8160106B2 (en) Method, device and system for transmitting Ethernet packets
US11700148B2 (en) Packet transmission method and device, and computer storage medium
US7385998B2 (en) Method and apparatus for encapsulating services for transportation over metallic physical mediums
CN107493238A (zh) 一种网络拥塞控制方法、设备及系统
WO2009081128A1 (fr) Méthode d'adaptation pour un trafic de communication
EP1124355A2 (fr) Mappage de 10 Gigabit-Ethernet pour une interface commune DMP LAN/WAN
EP2071808A1 (fr) Procédés, système et dispositifs de transmission de datagramme ipv6 sur ethernet
US7356035B1 (en) System and method for AAL5 enhanced encapsulation
CN117041143A (zh) 一种基于标签交换技术实现的卫星数据转发方法和系统
Xu et al. A Unified Framing Protocol for Hybrid Data Transport
JP2002335285A (ja) Atmアダプテーションレイヤ通信装置

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200880122095.7

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08863570

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2008863570

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 12808823

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE