WO2015027738A1 - 一种传输、接收元数据的方法、开放流逻辑交换机 - Google Patents

一种传输、接收元数据的方法、开放流逻辑交换机 Download PDF

Info

Publication number
WO2015027738A1
WO2015027738A1 PCT/CN2014/080387 CN2014080387W WO2015027738A1 WO 2015027738 A1 WO2015027738 A1 WO 2015027738A1 CN 2014080387 W CN2014080387 W CN 2014080387W WO 2015027738 A1 WO2015027738 A1 WO 2015027738A1
Authority
WO
WIPO (PCT)
Prior art keywords
metadata
message
ofls
field
ofcs
Prior art date
Application number
PCT/CN2014/080387
Other languages
English (en)
French (fr)
Inventor
梁乾灯
尤建洁
焦欣文
Original Assignee
中兴通讯股份有限公司
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
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2015027738A1 publication Critical patent/WO2015027738A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport

Definitions

  • the present invention relates to the field of SDN (Software Defined Network) architecture communication, and in particular, to a method for transmitting and receiving metadata, and an open flow logical switch.
  • SDN Software Defined Network
  • routers architecture such as OSPF, BGP, multicast, and differentiate. Services, traffic engineering, NAT, firewall, MPLS, and more. This makes switching devices such as routers more and more bloated and the space for performance improvement is getting smaller and smaller.
  • OpenFlow protocol separates the control plane of the network device from the data plane, thus achieving flexible control of network traffic and providing a good platform for innovation of core networks and applications.
  • the control plane contains an OFFlow controller (OpenFlow Controller), and the data plane includes an OpenFlow Capable Switch (OFCS, OpenFlow Capable Switch).
  • OFFlow Controller OpenFlow Controller
  • OFCS OpenFlow Capable Switch
  • the OpenFlow protocol is used to describe the criteria used for the interaction between the controller and the switch. And interface standards for controllers and switches.
  • the core part of the protocol is a collection of information structures for the OpenFlow protocol.
  • FIG. 2 shows the OpenFlow flow table and the flow table-based message processing flow.
  • the flow table contains multiple flow table entries.
  • the flow table entries consist of the following fields: matching fields, counters, and instruction sets:
  • Match Fields is an input keyword for matching messages, and is used to match a flow entry;
  • Counters is a variety of statistical information for management;
  • the instruction set refers to the operation instructions of the packet, including discarding, forwarding the packet to the specified port, setting the packet header field value, and adding the package label.
  • the Action Set is associated with each message, which is passed between multiple flow tables in the pipeline and modified by the instructions of each flow table until the pipeline processing ends, forming the final set of actions.
  • a plurality of flow tables are arranged into a flow table pipe, which is used to configure a switch forwarding path, and metadata (metadata) is carried between adjacent flow tables in the pipe (for example, tunnel id), so that
  • metadata metadata
  • the current flow table inherits the processing results of the upper-level process, simplifies the matching domain or avoids repeated work, effectively makes the associated flow tables in the pipeline work together, and makes the flow table on the pipeline simpler.
  • the technical problem to be solved by the embodiments of the present invention is to provide a method for transmitting and receiving metadata, an open flow logical switch, and reducing repetitive work between nodes of an SDN network.
  • a method of transmitting metadata applied to a software defined network SDN comprising: The OpenFlow logical switch OFLS on the OpenFlow Capability Switch OFCS inserts or modifies metadata in the first packet to generate a second packet carrying the metadata.
  • the current OFCS passes the second message to the next level OFCS according to the action indicated by the flow table entry matching the second message.
  • the metadata includes: a feature part and a content part
  • the characteristic part includes: transmission mode information of the second packet carrying the metadata and identification mode information of the metadata; wherein the transmission mode information is used to determine when the second message transmits metadata
  • the bearer mode is used to determine the identifier value of the bearer type expected by the OFCS in the bearer mode;
  • the content portion of the metadata contains business attribute information.
  • the transmission mode information indicates that the metadata of the second packet transmission is carried in an Ethernet layer, and the identification mode information is an Ethernet type expected value of the OFCS; or
  • the transmission mode information indicates that the metadata of the second packet transmission is carried in an IP layer, and the identification mode information is a value of an IP protocol type expected by the OFCS; or
  • the transmission mode information indicates that the metadata of the second packet transmission is carried in the UDP layer, and the identification mode information is a value of the UDP destination port type expected by the OFCS.
  • the OFCS in the SDN supports metadata in a plurality of different formats, where a content part of the metadata includes a first identifier field, and a value of the first identifier field is determined according to a format of the metadata.
  • the content part of the metadata includes a second identifier field, and the value of the identifier field of the first packet bearer is saved in the second identifier field.
  • the method further includes: the OFDM receiving the first flow table entry delivered by the OF controller, and the action of the write-action command of the first flow entry
  • the parameter set includes an extended action
  • the extended action includes pushing metadata.
  • the push metadata action includes the following parameters: a bearer mode of the second packet carrying the metadata, and an expected bearer type of the OFCS in the bearer mode. An identification value and a format identifier of the metadata;
  • the step of inserting the metadata into the first message by the OFDM is:
  • the OFLS matches the first packet to the first flow table entry, and inserts a content part of the metadata in a corresponding position in the first packet according to a bearer manner in the parameter, where the content part is
  • the value of the identifier field of the first packet bearer header is written in the identifier field, and then the value of the identifier field of the first packet bearer header is modified to the identifier value of the bearer type expected by the 0FCS in the parameter.
  • the expanding action further includes setting a metadata field, where the setting metadata field action includes the following parameters: a field offset, a field size, a value type to be set, and a value;
  • the step of modifying the metadata in the first packet by the OFLS includes:
  • the OFLS sets the value of the metadata field pointed to by the field offset parameter to the value parameter.
  • An information configuration method is applied to a software defined network SDN, and the method includes:
  • the OpenFlow Capability Switch 0FCS in the SDN receives the configuration of the metadata format of the first node
  • the OpenFlow logical switch OFLS on the 0FCS receives the configuration of the metadata format bound by the first node to the OFLS.
  • the first node includes: an OF configuration point, an OF controller, a network management system NMS, and an 0FCS local;
  • the method further includes: attaching the OFLS to the OF controller that is linked to the OFLS The specified metadata format.
  • the step of reporting, by the OFLS, the metadata format of the OFLS binding to the OF controller that is linked to the OFLS includes:
  • the OFLS actively reports the bound metadata format to the chained OF controller through the extended dedicated asynchronous message.
  • the step of reporting, by the OFLS, the metadata format of the OFLS binding to the OF controller that is linked to the OFLS includes:
  • the query request message and the metadata format query response message perform the query and the upper metadata format of the OFLS binding.
  • a method for receiving metadata which is applied to a software-defined network SDN, the method includes: after receiving the packet, the OpenFlow capability switch OFCS in the SDN identifies the metadata carried in the packet, and parses the content portion of the metadata. And directing the content portion of the message and/or the metadata to a logical service node on the OFCS for processing.
  • the step of the OFCS parsing the content part of the metadata includes:
  • the OFCS parses the metadata content portion according to the format of the metadata indicated by the first identification field in the metadata content portion.
  • the step of the OFCS directing the content part of the message and/or the metadata to the logical service node on the OFCS comprises:
  • the OFCS when the content part of the metadata includes an OpenFlow logical switch OFLS identifier field, determining an OFLS to which the content part of the message and/or metadata is directed according to the OFLS identifier field; or
  • the OFCS directs the content part of the “3 ⁇ 4 text and/or metadata to the OFLS according to the configured flow mapping policy; or, the OFCS is
  • the content portion of the metadata includes a service node identification field
  • the content portion of the message and/or metadata is directed to the service instance pointed to by the service node identification field.
  • the method before the processing by the logical service node, the method further includes:
  • the logical service node receives the second flow table entry sent by the OF controller, where the matching domain of the second flow table entry includes an extended metadata field;
  • the step of processing by the logical service node includes:
  • the logical service node uses the flow classification identifier field included in the content part of the metadata as a matching key value on the flow table of the flow table pipeline.
  • the action parameter set of the write-action instruction of the second flow table entry includes an extended action
  • the extended action includes pop-up metadata
  • the pop-up metadata action includes the following parameters: The bearer type of the data and the second identifier field
  • the step of processing by the logical service node further includes:
  • the logical service node strips the metadata from the message and backfills the value of the second identification field of the content portion of the metadata with the identification field of the bearer header of the message.
  • An open flow logical switch includes: a first unit, wherein:
  • the first unit is configured to: insert or modify metadata in the first packet, and generate a second packet carrying the metadata.
  • the metadata includes: a feature part and a content part
  • the characteristic part includes: a transmission mode information of the second packet carrying the metadata and a identification mode information of the metadata; wherein the transmission mode information determines a bearer mode when the second packet transmits the metadata; Determining, by the information, an identifier value of a bearer type expected by the open flow capability switch OFCS in the bearer mode;
  • the content portion of the metadata contains business attribute information.
  • the content part of the metadata includes a first identifier field, and the value of the first identifier field is determined according to a format of the metadata; the content part of the metadata further includes a second identifier field, where The value of the identifier field of the first packet bearer is saved in the second identifier field.
  • the open flow logical switch further includes a receiving unit, where:
  • the receiving unit is configured to: receive a first flow table entry delivered by the OF controller, where the action parameter set of the write-action instruction of the first flow table entry includes an extended action, where the extended action includes pushing metadata, the pushing
  • the metadata input action includes the following parameters: a bearer mode of the second packet carrying the metadata, an identifier value of the bearer type expected by the OFCS in the bearer mode, and a format identifier of the metadata;
  • the first unit is configured to insert metadata in the first packet according to the following manner: matching the first packet to the first flow table entry, according to the bearer mode in the parameter, in the first packet The corresponding location is inserted into the content part of the metadata, the value of the identifier field of the first packet bearer header is written in the second identifier field of the content part, and then the value of the identifier field of the first packet bearer header is modified to The identification value of the bearer type expected by the OFCS in the parameter.
  • the expanding action further includes setting a metadata field, where the setting metadata field action includes the following parameters: a field offset, a field size, a value type to be set, and a value;
  • the first unit is arranged to modify the metadata in the first message as follows:
  • the value of the metadata field pointed to by the field offset parameter is set to the numerical parameter.
  • the OpenFlow logical switch further includes a matching unit, where:
  • the receiving unit is further configured to: receive, by the OF controller, a second flow table entry, where the matching domain of the second flow entry includes an extended metadata field;
  • the matching unit is configured to: use a flow classification identifier field included in a content portion of the metadata as a matching key value on a flow table of the flow table pipeline.
  • the OpenFlow logical switch further includes a second unit, where:
  • the action parameter set of the write-action instruction of the second flow table entry includes an extended action, the extended action includes pop-up metadata, and the pop-up metadata action includes the following parameters: a bearer type of the metadata and a second identifier field ;
  • the second unit is configured to: strip the metadata from the message, and backfill the value of the second identification field of the content portion of the metadata into the identification field of the bearer header of the message.
  • An open flow capable switch comprising: an identification parsing unit and a guiding unit, wherein: the identification parsing unit is configured to: identify metadata carried in the received message, and parse the content part of the metadata;
  • the boot unit is arranged to: direct the message and/or the content portion of the metadata to a logical service node on the open flow capability switch OFCS for processing.
  • the identification parsing unit is configured to parse the content portion of the metadata in a manner of: parsing the metadata content portion according to a format of the metadata indicated by the first identification field in the metadata content portion.
  • the guiding unit is configured to direct the message and/or the content portion of the metadata to the logical service node on the OFCS as follows:
  • the root Determining an OFLS to which the content portion of the message and/or metadata is directed according to the OFLS identification field;
  • the content part of the metadata includes a flow classification identifier field
  • the content part of the message and/or metadata is directed to the OFLS according to the configured flow mapping policy
  • the content portion of the metadata includes a service node identification field
  • the content portion of the message and/or metadata is directed to the service instance pointed to by the service node identification field.
  • the foregoing solution can reduce the work of the next OFLS and the previous OFLS by carrying the metadata in the packets transmitted between the OFLSs, thereby saving some resources.
  • FIG. 1 is a schematic diagram of an OF-Config protocol and an OpenFlow protocol in the related art
  • FIG. 2 is a schematic diagram of packet processing based on each flow table in the related art
  • FIG. 3 is a schematic diagram of a related art packet flow through an OpenFlow processing pipeline
  • FIG. 5 is a flowchart of an information configuration method according to an embodiment of the present invention.
  • FIG. 6 is a flowchart of a method of receiving metadata according to an embodiment of the present invention.
  • FIG. 7 is a network architecture diagram of metadata transfer between OFCSs according to an embodiment of the present invention
  • FIG. 8 is a message encapsulation format when a metadata application is carried in different bearer modes according to an embodiment of the present invention
  • FIG. 9 is an example of delivery of a metadata through a three-layer network according to an embodiment of the present invention.
  • FIG. 10 is an architectural diagram of an open flow logical switch according to an embodiment of the present invention.
  • FIG. 11 is a block diagram of an OpenFlow Capability Switch according to an embodiment of the present invention.
  • Preferred embodiment of the invention In the present application, when multiple OFCSs form an SDN network, for example, for traffic classification and the like, if the intermediate node cannot utilize the result of the stream classification processing of the edge node, it needs to consume more resources to repeat the flow classification. Therefore, this application transfers the metadata metadata between the OFCSs, and solves the problem that the intermediate nodes cannot utilize the stream classification processing of the edge nodes, and needs to consume more resources to repeat the work of the stream classification.
  • metadata is transmitted between the forwarding nodes, and metadata can be carried on the metadata-aware intermediate network to carry information that is of interest to each other.
  • the embodiments of the present invention are directed to solving the above problems and provide a solution for transferring metadata between OFCSs.
  • the method for transmitting metadata in this embodiment includes:
  • Step 401 The OpenFlow logical switch OFLS on the current OFCS inserts or modifies metadata in the first packet to generate a second packet carrying the metadata.
  • the first message is sent to the current OFCS by other logical questions.
  • Step 402 The current OFCS delivers the second message to the next level OFCS according to the action indicated by the flow table entry matching the second packet.
  • the flow table entry refers to: a flow entry in the flow table in the OFCS, and each item is called a flow table entry.
  • Metadata metadata carried by the packets between the OFCSs for example, the intermediate OFCS or the traditional forwarding device only pays attention to the MAC header information, and the metadata carried by the packets is carried on the UDP layer.
  • the metadata includes: a characteristic part and a content part; the characteristic part includes: a transmission mode information of the second message carrying the metadata and a identification mode information of the metadata; wherein, the transmission mode information determines a bearer when the second message transmits the metadata
  • the identification mode information determines an identifier value of the bearer type expected by the OFCS in the bearer mode; the content part of the metadata includes the service attribute information.
  • the transmission mode information indicates that the metadata of the second message transmission is carried in the Ethernet layer, and the identification mode information is an Ethernet type value expected by the OFCS; or the transmission mode information indicates that the metadata of the second message transmission is carried on the IP layer.
  • the identification mode information is the value of the IP protocol type expected by the OFCS; or, the transmission mode information indicates that the metadata of the second message transmission is carried on the UDP layer, and the identification mode information is the value of the UDP destination port type expected by the OFCS.
  • the OFCS in SDN supports metadata in a plurality of different formats, and the content portion of the metadata includes a first identification field (metadata ID), and the value of the first identification field is determined according to the format of the metadata.
  • the content portion of metadata in different metadata formats contains one or more different types of fields.
  • the first identification field is used to identify the format in which the metadata is used.
  • the content part of the metadata includes a second identification field, and the value of the identification field of the first message carrying header before the metadata is inserted is stored in the second identification field.
  • the identifier field of the second packet bearer layer may be backfilled with the value of the second identifier field in the metadata.
  • the metadata is carried on the Ethernet header, the original Ethernet type of the Ethernet header of the first packet is 0x0800, and the value of the expected Ethernet type of the metadata is 0xa811. After the metadata is inserted into the first packet, the Ethernet type of the Ethernet header is used.
  • the second identifier field of the metadata is consistent with the size of the Ethertype, and the padded value is 0x0800.
  • the value of the second identifier field of the metadata is used to backfill the etheric type of the Ether, so that the ether The etheric type of the header is restored to 0x0800.
  • the OF controller determines the 0FLS and the next level on the current OFCS according to the requirements of the service deployment.
  • the metadata of the piggyback meets the metadata format supported by the next level OFCS.
  • the OFLS receives the first flow table entry delivered by the OF controller, where the first flow table entry is used to process a type of message, and the action parameter set of the write-action instruction of the first flow table entry includes an extended action, and the extended action includes pushing the metadata.
  • push-metadata indicating that the metadata is inserted into the specified location of the packet matching the hitting entry, and the push metadata action includes the following parameters: a bearer mode of the second packet carrying the metadata, and an expected bearer of the 0FCS in the bearer mode.
  • the OFLS inserts metadata in the first packet, including:
  • 0FLS matches the first packet to the first flow table entry, inserts the content part of the metadata specified by the metadata ID in the corresponding position in the first message according to the bearer mode in the parameter, and writes in the second identifier field of the content part. Enter the value of the identifier field of the first packet bearer header, and then modify the value of the identifier field of the first packet bearer header to the identifier value of the bearer type expected by the 0FCS in the parameter.
  • the extension action also includes setting a metadata field (set-metadata-field), and setting the metadata field action includes the following parameters: field offset, field size, value type to be set, and value;
  • the OFLS modifies the metadata in the first packet, including:
  • the OFLS sets the value of the metadata field pointed to by the field offset parameter to a numeric parameter.
  • the embodiment further provides an information configuration method, which is applied to the SDN, and includes:
  • Step 501 The 0FCS in the SDN receives the configuration of the first node to the metadata format.
  • the first node includes: OF configuration point, OF controller, network management system NMS, and 0FCS local.
  • 0FCS checks the configuration of the metadata format of the above source, and responds to the configuration error message when it finds that the configuration is incorrect or the resolution of the metadata format is not recognized.
  • the method further includes: the OFLS reporting the metadata bound to the OFLS to the OF controller that is linked with the OFLS format.
  • the OFLS reports the metadata format of the OFLS binding to the OF controller that is linked to the OFLS, and includes: the OFLS actively reports the bound metadata format to the established OF controller through the extended dedicated asynchronous message; or, OFLS Querying and reporting the metadata format of the OFLS binding by querying the request message and the metadata format query response message with a set of metadata formats extended in the Multipart message.
  • the embodiment further provides a method for receiving metadata, which is applied to an SDN, and includes:
  • Step 601 After receiving the packet, the OFCS in the SDN identifies the metadata carried in the packet, and parses the content part of the metadata.
  • Step 602 The OFCS directs the content portion of the message and/or metadata to the logical service node on the OFCS for processing.
  • the OFCS parses the content portion of the metadata, including: the OFCS parses the metadata content portion according to the format of the metadata indicated by the first identification field in the metadata content portion.
  • the OFCS directs the content part of the message and/or the metadata to the logical service node on the OFCS, including: When the content part of the metadata includes the OFLS identifier (OFLS-ID) field, the OFCS determines the packet and the according to the OFLS identification field. / or OFLS to which the content portion of the metadata is directed; or,
  • OFLS-ID OFLS identifier
  • the OFCS directs the content part of the text and/or metadata to the OFLS according to the configured flow mapping policy; or, the OFCS is in the metadata
  • the content portion contains a Service Node Identity (Server-node-ID) field
  • the content portion of the message and/or metadata is directed to the service instance pointed to by the Service Node Identity field.
  • Flow-ID flow classification identifier
  • the logical service node Before the logical service node processes it, it includes:
  • the logical service node receives the second flow table entry from the OF controller, and is configured to process the metadata-carrying message transmitted by the OFLS on the upper-level OFCS, where the matching field of the second flow table entry includes the extended metadata field.
  • a matching key value such as metadata-field [id], which is the field identifier of the metadata;
  • the logical service node processes, including:
  • the logical service node uses the flow classification identifier (Flow-ID) field contained in the content part of the metadata as the matching key value in the flow table of the flow table pipe (the entry matching field of the flow table includes the flow classification identifier field matching the metadata) .
  • Flow-ID flow classification identifier
  • the action parameter set of the write-action instruction of the second flow table entry includes an extended action: pop-metadata, and the pop-up metadata action includes the following parameters: a bearer type of the metadata and a second identifier field;
  • the logical service node processes, and also includes:
  • the logical service node strips the metadata from the message and backfills the value of the second identification field of the content portion of the metadata with the identification field of the bearer header of the message.
  • Embodiment 1 is an XML example defined by metadata in accordance with the present invention.
  • the metadata definition contains two parts: feature and content:
  • Feature indicates the way to define the transfer or i only 1 J metadata:
  • the port example (1) indicates that the metadata is carried on the ether; optionally, the message type encapsulated by the metadata can also be specified in the feature field, as in the example (1) Set the packet type encapsulated by metadata to ethertype.
  • Example (2) means that metadata is on IP; example (3) means that metadata is on UDP.
  • the Content is the body of the metadata. It is generally recommended that the first IByte be defined as the metadata format ID (that is, each feature type metadata can define up to 256 formats); the second IByte is defined as the length of the metadata, and the metadata length is no more than 64 bytes; other fields They are all defined in the form of ⁇ size, name>.
  • the carrier layer is the etheric head
  • the field name ID which represents the ID of the metadata type
  • the bearer layer is the IP header.
  • IP header protocol type for identifying metadata is 0x0a47 ⁇ /feature>
  • protocol-type protocol-type ⁇ /name>; saves the value of the protocol type field of the original IP header before the metadata is inserted.
  • Embodiment 2 is an action action of an OF controller to OFLS flow table extended according to the present invention: metadata ⁇ push-metadata, pop-metadata, and set-metadata-field actions.
  • Push metadata ⁇ type> ⁇ value> ⁇ id> pop metadata ⁇ type> ⁇ id> type indicates the feature type of metadata, the value is
  • Size indicates the size of the metadata space
  • Value represents the eigenvalue of metadata.
  • Size indicates the size of the selected field.
  • Source-type indicates the data source type of the metadata content field. The value is
  • FIX indicates that the value is set by the controller, that is, the target-value is written to the specified offset position.
  • PACKET indicates that the value comes from a field of the message, and the field of the value is set by the controller.
  • LOCAL indicates that the value is generated locally by the OFLS forwarding plane, such as a 32-bit random value or a 64-bit timestamp (or a formatted timestamp).
  • METADATA indicates that the value comes from a field in the metadata passed by the previous OFLS.
  • Target-value indicates the value to be filled in the selected field. It can be a fixed value set by the controller, or it can be the value of a certain setting field of the received message specified by the controller.
  • Embodiment 3 is an operation example of the metadata mapping policy performed on the OFCS according to the present invention.
  • the current OFCS receives the metadata-bearing message transmitted by the OFLS on the upper-level OFCS, and then reads the metadata content (such as OFLS-id) according to the format of the agreed metadata, and performs corresponding operations.
  • the metadata content such as OFLS-id
  • the mapping module guides the >3 ⁇ 4 text according to the value of the OFLS-id field to OFLS1 performs processing of the flow table pipeline.
  • Embodiment 4 is a network architecture diagram of metadata transmitted between OFCSs according to the present invention (as shown in FIG. 7).
  • the OpenFlow edge forwarding node receives the packet from the traditional network, and generates the metadata after local processing. According to the agreed metadata format, the PDU is encapsulated by using metadata, and then carried on the L2/L3/L4 transmission protocol for transmission. Optionally, when another OpenFlow edge forwarding node receives the packet from the OpenFlow network, the metadata is stripped from the packet according to the format of the agreed metadata, and then sent to the forwarding device of the traditional network.
  • the embodiment 5 is a packet encapsulation format when the metadata application is carried in different bearer modes according to the present invention.
  • the Ethertype of the Ethertype header of the setting is Oxyyyy, indicating that the metadata is loaded with Ethernet.
  • the protocol type of the IP header of the packet is set to ⁇ , indicating that the metadata is encapsulated using IP.
  • the Dport of the UDP header of the packet is set to xxxxx, indicating that the metadata is encapsulated using UDP.
  • Embodiment 6 is an example of the transfer of metadata across a three-layer network in accordance with the present invention.
  • the OpenFlow edge forwarding node After receiving the packet from the OpenFlow network, the OpenFlow edge forwarding node reads the content of the metadata 1 according to the format of the agreed metadata (meport flow-id, next-OFLS-id, dpi-). Instance-id, etc., and perform the corresponding operations.
  • the OpenFlow edge forwarding node transmits the metadata2 generated by the local processing to the outer UDP header of the analog VXLAN tunnel according to the analog VXLAN tunnel, and sets the destination port of the UDP to zzzzz.
  • the PDU is encapsulated by VLAN (optional), Ethernet, and then encapsulated by metadata2. After the packet is encapsulated, the packet is sent to the peer OpenFlow edge forwarding node.
  • the peer OpenFlow edge forwarding node strips the metadata2 from the packet according to the simulated VXLAN tunnel and synchronizes the virtual interface on the simulated VXLAN tunnel.
  • the UDP header, the IP header, and the Ethernet header are encapsulated to obtain the original Layer 2 packet of the tenant, and the packet is processed accordingly.
  • the PDU is encapsulated using metadata3 according to the definition of the agreed metadata, and then carried on the L2 transport protocol for transmission.
  • this embodiment provides an OpenFlow logical switch, including: a first unit 1001, where:
  • the first unit 1001 is configured to: insert or modify metadata in the first packet to generate a second packet carrying the metadata.
  • the metadata contains: a feature part and a content part;
  • the characteristic part includes: a transmission mode information of the second packet carrying the metadata and a identification mode information of the metadata; wherein, the transmission mode information determines a bearer mode when the second packet transmits the metadata; and the identification mode information is determined to be open under the bearer mode
  • the content portion of the metadata contains business attribute information.
  • the content part of the metadata includes a first identifier field, and the value of the first identifier field is determined according to the format of the metadata; the content part of the metadata further includes a second identifier field, where the first packet carrying header is saved in the second identifier field Identifies the value of the field.
  • the transmission mode information indicates that the second message is carried in the Ethernet layer when the metadata is transmitted, and the identification mode information is the value of the Ethernet type expected by the OFCS; or the transmission mode information indicates that the second message is carried in the IP layer when the metadata is transmitted, and the identification manner is The information is the value of the IP protocol type expected by the OFCS; or, the transmission mode information indicates that the second message is carried in the UDP layer when the metadata is transmitted, and the identification mode information is the value of the UDP destination port type expected by the OFCS.
  • the open flow logical switch also includes a receiving unit 1002, wherein:
  • the receiving unit 1002 is configured to: receive a first flow table entry sent by the OF controller, where the action parameter set of the write-action instruction of the first flow table entry includes an extended action: pushing the metadata, and the pushing the metadata action includes the following parameters: The bearer mode of the second packet carrying the metadata, the identifier value of the bearer type expected by the OFCS in the bearer mode, and the format identifier of the metadata;
  • the first unit 1001 is configured to insert metadata in the first packet according to the following manner: matching the first packet to the first flow table entry, and inserting the metadata in the corresponding position in the first packet according to the bearer mode in the parameter.
  • the value of the identifier field of the first packet bearer header is written in the second identifier field of the content part, and then the value of the identifier field of the first packet bearer header is modified to the identifier of the bearer type expected by the OFCS in the parameter. value.
  • the extended actions also include: setting a metadata field, and setting the metadata field action includes the following parameters: field offset, field size, value type to be set, and value;
  • the first unit is arranged to modify the metadata in the first message as follows:
  • the value of the metadata field pointed to by the field offset parameter is set to a numeric parameter.
  • the open flow logical switch also includes a matching unit 1003, wherein:
  • the receiving unit 1002 is further configured to: receive the second flow table entry by the receiving OF controller, where the matching field of the second flow table entry includes an extended metadata field; the matching unit 1003 is configured to: on the flow table of the flow table pipe The stream classification identifier field contained in the content portion of the metadata is used as the matching key value.
  • the OpenFlow logical switch further includes a second unit 1004, wherein: the action parameter set of the write-action instruction of the second flow table entry includes an extended action: pop-up metadata, and the pop-up metadata action includes the following parameters: a bearer type of the metadata and a second identity field; the second unit 1004 is configured to: strip the metadata from the message, and backfill the value of the second identity field of the content portion of the metadata into the identity field of the bearer header of the message.
  • the embodiment further provides an open flow capability switch, including: an identification parsing unit 1101 and a guiding unit 1102, where: the identification parsing unit 1101 is configured to: identify metadata carried in the received packet. , parsing the content portion of the metadata;
  • the boot unit 1102 is arranged to: direct the content portion of the message and/or metadata to the logical service node on the OpenFlow Capability Switch OFCS for processing.
  • the identification parsing unit 1101 is configured to parse the content portion of the metadata as follows: The format of the metadata indicated by the first identification field in the data content portion parses the metadata content portion.
  • the boot unit 1102 is arranged to direct the content portion of the message and/or metadata to the logical service node on the OFCS as follows:
  • the OFLS identification field determines the OFLS to which the content portion of the message and/or metadata is directed; or, when the content portion of the metadata includes the flow classification identification field, the message and/or metadata is based on the configured flow mapping policy The content portion is directed to the OFLS; or,
  • the content portion of the metadata contains the service node identification field
  • the content portion of the message and/or metadata is directed to the service instance pointed to by the service node identification field.
  • each module/unit in the foregoing embodiment may be implemented in the form of hardware, or may use software functions.
  • the form of the module is implemented. This application is not limited to any specific form of combination of hardware and software.
  • the foregoing solution can reduce the work of the next OFLS and the previous OFLS by carrying the metadata in the packets transmitted between the OFLSs, thereby saving some resources. Therefore, the present invention has strong industrial applicability.

Abstract

一种传输、接收元数据的方法、开放流逻辑交换机，所述传输元数据的方法，应用于软件定义网络SDN，该方法包括：当前开放流能力交换机OFCS上的开放流逻辑交换机OFLS在第一报文中插入或修改元数据，生成携带所述元数据的第二报文；当前OFCS根据匹配的流表条目指示的动作将所述第二报文传递给下一级OFCS。上述技术方案通过在OFLS之间传递的报文中携带元数据，可以减少下一个OFLS进行与上一个OFLS相重复的工作，从而节省部分资源。

Description

一种传输、 接收元数据的方法、 开放流逻辑交换机
技术领域
本发明涉及软件定义网络（SDN, Software Defined Network ) 架构通信 领域， 尤其涉及一种传输、 接收元数据的方法、 开放流逻辑交换机。
背景技术
由于现在的网络暴露出了越来越多的弊病以及人们对网络性能的需求越 来越高， 研究人员不得不把很多复杂功能加入到路由器的体系结构当中， 例 如 OSPF、 BGP、 组播、 区分服务、 流量工程、 NAT、 防火墙、 MPLS等等。 这就使得路由器等交换设备越来越臃肿而且性能提升的空间越来越小。
然而， 与网络领域的困境截然不同的是， 计算机领域实现了日新月异的 发展。 仔细回顾计算机领域的发展， 不难发现其关键在于计算机领域找到了 一种简单可用的硬件底层 （x86 指令集） 。 由于有了这样一种公用的硬件底 层， 所以在软件方面， 不论是应用程序还是操作系统都取得了飞速的发展。 现在很多主张重新设计计算机网络体系结构的人士认为： 网络可以复制计算 机领域的成功来解决现在网络所遇到的所有问题。 在这种思想的指导下， 将 来的网络必将是这样的： 底层的数据通路（交换机、 路由器）是"哑的、 简单 的、 最小的"， 并定义一个对外开放的关于流表的公用的 API, 同时釆用控制 器来控制整个网络。 未来的研究人员就可以在控制器上自由的调用底层的 API来编程， 从而实现网络的创新。
基于上述的理念， 出现了 SDN, 其最初是由美国斯坦福大学 clean slate 研究组提出的一种新型网络创新架构。 目前， 其核心技术开放流 OpenFlow 协议（请参考图 1 )通过将网络设备控制面与数据面分离开来， 从而实现了 网络流量的灵活控制， 为核心网络及应用的创新提供了良好的平台。 控制面 包含 OF 控制器 （OpenFlow Controller ) , 数据面包含开放流能力交换机 ( OFCS , OpenFlow Capable Switch )
OpenFlow协议用来描述控制器和交换机之间交互所用信息的标准， 以 及控制器和交换机的接口标准。 协议的核心部分是用于 OpenFlow协议信息 结构的集合。
如图 2所示为 OpenFlow流表和基于流表的报文处理流程， 流表中包含多 个流表条目， 流表条目由匹配字段、 计数器和指令集等如下几个字段构成：
Figure imgf000004_0001
其中 , Match Fields是报文匹配的输入关键字， 用于匹配一条流表项； 计数器 Counters是管理用的各种统计信息；
指令集（Instructions )是指对报文的操作指令， 包括丟弃、 转发报文到指 定端口、 设置报文头部字段值、 增加封装标签等。
动作集（ Action Set )和每个报文相关联， 它在流水线的多个流表之间传 递并被各流表的指令所修改， 直到流水线处理结束， 形成最终的动作集。
如图 3所示， 经过编排的多个流表级联成流表管道， 用来配置交换机转 发路径， 管道内相邻流表间釆用 metadata (元数据）携带数据（例如 tunnel id ) , 以便当前流表继承利用上一级流程的处理成果， 简化匹配域或避免重 复工作， 有效的让管道内关联的流表协同工作， 让管道上的流表更简单。
当多个 OF交换机形成一个 SDN网络时， 流量在该网络上流经多个 OF 交换机， 相当于将多个 OF 交换机的流表管道连接成一个更长的虚拟管道。 由于一般 SDN 网络的中间节点会汇聚交换边缘节点的流量， 导致中间节点 需要更多的流表条目信息来实现流转发， 需要消耗更多的资源来重复进行流 分类的工作。
发明内容
本发明实施例要解决的技术问题是提供一种传输、 接收元数据的方法、 开放流逻辑交换机， 减少 SDN网络的节点间的重复工作。
为解决上述技术问题， 釆用如下技术方案：
一种传输元数据的方法， 应用于软件定义网络 SDN, 该方法包括： 当前开放流能力交换机 OFCS上的开放流逻辑交换机 OFLS在第一报文 中插入或修改元数据， 生成携带所述元数据的第二报文；
当前 OFCS根据与所述第二报文匹配的流表条目指示的动作将所述第二 报文传递给下一级 OFCS。
可选地， 所述元数据包含： 特性部分和内容部分；
所述特性部分包含： 携带所述元数据的所述第二报文的传输方式信息和 所述元数据的识别方式信息； 其中， 所述传输方式信息用于确定第二报文传 输元数据时的承载方式； 所述识别方式信息用于确定所述承载方式下 OFCS 预期的承载类型的标识值；
所述元数据的内容部分包含业务属性信息。
可选地， 所述传输方式信息表示所述第二报文传输的元数据承载于以太 层， 所述识别方式信息为 OFCS预期的以太类型的值； 或者，
所述传输方式信息表示所述第二报文传输的元数据承载于 IP层， 所述识 别方式信息为 OFCS预期的 IP协议类型的值； 或者，
所述传输方式信息表示所述第二报文传输的元数据承载于 UDP层，所述 识别方式信息为 OFCS预期的 UDP目的端口类型的值。
可选地， 所述 SDN中的 OFCS支持多种不同格式的元数据， 所述元数据 的内容部分包含第一标识字段， 所述第一标识字段的值根据所述元数据的格 式确定。
可选地， 所述元数据的内容部分包含第二标识字段， 在所述第二标识字 段中保存所述第一报文承载头的标识字段的值。
可选地， 所述 0FLS在第一报文中插入元数据之前， 该方法还包括： 所述 0FLS接收 OF控制器下发的第一流表条目， 该第一流表条目的写- 动作指令的动作参数集中包含扩展动作， 所述扩展动作包括推入元数据， 所 述推入元数据动作包括以下参数： 携带元数据的第二报文的承载方式、 所述 承载方式下 OFCS预期的承载类型的标识值和所述元数据的格式标识；
所述 0FLS在第一报文中插入元数据的步骤包括： 所述 OFLS将所述第一报文匹配到所述第一流表条目， 根据所述参数中 的承载方式在第一报文中对应的位置插入所述元数据的内容部分， 在内容部 分的第二标识字段中写入第一报文承载头的标识字段的值， 然后将第一报文 承载头的标识字段的值修改为所述参数中 0FCS预期的承载类型的标识值。
可选地， 所述扩展动作还包括设置元数据字段， 所述设置元数据字段动 作包括以下参数： 字段偏移、 字段大小、 待设置值类型和数值；
所述 OFLS在第一报文中修改元数据的步骤包括：
所述 OFLS将所述字段偏移参数指向的元数据字段的数值设置为所述数 值参数。
一种信息配置方法， 应用于软件定义网络 SDN, 该方法包括：
所述 SDN中的开放流能力交换机 0FCS接收第一节点对元数据格式的配 置；
所述 0FCS上的开放流逻辑交换机 OFLS接收所述第一节点对所述 OFLS 绑定的元数据格式的配置。
可选地，所述第一节点包括： OF配置点、 OF控制器、网络管理系统 NMS 和 0FCS本地；
在所述绑定的元数据格式由所述 OF配置点、 网络管理系统或 0FCS本 地配置时， 所述方法还包括： 所述 OFLS向与该 OFLS建链的 OF控制器上才艮 该 OFLS绑定的元数据格式。
可选地， 所述 OFLS向与该 OFLS建链的 OF控制器上报该 OFLS绑定的 元数据格式的步骤包括：
所述 OFLS通过扩展的专用异步消息将绑定的元数据格式主动上报给所 述建链的 OF控制器。
可选地， 所述 OFLS向与该 OFLS建链的 OF控制器上报该 OFLS绑定的 元数据格式的步骤包括：
所述 OFLS与 OF控制器之间通过 Multipart消息中扩展的一组元数据格 式查询请求消息和元数据格式查询应答消息， 进行 OFLS绑定的元数据格式 的查询和上才艮。
一种接收元数据的方法， 应用于软件定义网络 SDN, 该方法包括： 所述 SDN中的开放流能力交换机 OFCS接收到报文后，识别报文中携带 的元数据， 解析元数据的内容部分， 将报文和 /或所述元数据的内容部分引导 到所述 OFCS上的逻辑服务节点进行处理。
可选地， 所述 OFCS解析元数据的内容部分的步骤包括：
所述 OFCS 根据元数据内容部分中的第一标识字段指示的元数据的格 式， 对元数据内容部分进行解析。
可选地，所述 OFCS将报文和 /或所述元数据的内容部分引导到所述 OFCS 上的逻辑服务节点的步骤包括：
所述 OFCS在所述元数据的内容部分包含开放流逻辑交换机 OFLS标识 字段时， 根据所述 OFLS标识字段确定将所述报文和 /或元数据的内容部分引 导到的 OFLS; 或者，
所述 OFCS在所述元数据的内容部分包含流分类标识字段时， 根据已配 置的流映射策略将所述"¾文和 /或元数据的内容部分引导到 OFLS上； 或者， 所述 OFCS在所述元数据的内容部分包含服务节点标识字段时， 将所述 报文和 /或元数据的内容部分引导到服务节点标识字段指向的服务实例上。
可选地， 所述逻辑服务节点进行处理之前， 该方法还包括：
所述逻辑服务节点接收 OF控制器下发第二流表条目， 该第二流表条目 的匹配域中包含扩展的元数据字段；
所述逻辑服务节点进行处理的步骤包括：
所述逻辑服务节点在流表管道的流表上釆用元数据的内容部分包含的流 分类标识字段作为匹配键值。
可选地， 在所述第二流表条目的写-动作指令的动作参数集中包含扩展动 作， 所述扩展动作包括弹出元数据， 所述弹出元数据动作包括以下参数： 元 数据的承载类型和第二标识字段；
所述逻辑服务节点进行处理的步骤还包括：
所述逻辑服务节点从报文中剥离元数据， 并将元数据的内容部分的第二 标识字段的值回填报文的承载头的标识字段。
一种开放流逻辑交换机， 包括： 第一单元， 其中：
所述第一单元设置成： 在第一报文中插入或修改元数据， 生成携带所述 元数据的第二报文。
可选地， 所述元数据包含： 特性部分和内容部分；
所述特性部分包含： 携带元数据的第二报文的传输方式信息和元数据的 识别方式信息； 其中， 所述传输方式信息确定第二报文传输元数据时的承载 方式； 所述识别方式信息确定所述承载方式下开放流能力交换机 OFCS预期 的承载类型的标识值；
所述元数据的内容部分包含业务属性信息。
可选地， 所述元数据的内容部分包含第一标识字段， 所述第一标识字段 的值根据所述元数据的格式确定； 所述元数据的内容部分还包含第二标识字 段， 在所述第二标识字段中保存所述第一报文承载头的标识字段的值。
可选地， 所述开放流逻辑交换机还包括接收单元， 其中：
所述接收单元设置成： 接收 OF控制器下发的第一流表条目， 该第一流 表条目的写 -动作指令的动作参数集中包含扩展动作， 所述扩展动作包括推入 元数据， 所述推入元数据动作包括以下参数： 携带元数据的第二报文的承载 方式、 所述承载方式下 OFCS预期的承载类型的标识值和所述元数据的格式 标识；
所述第一单元设置成按照如下方式在第一报文中插入元数据： 将所述第 一报文匹配到所述第一流表条目， 根据所述参数中的承载方式在第一报文中 对应的位置插入所述元数据的内容部分， 在内容部分的第二标识字段中写入 第一报文承载头的标识字段的值， 然后将第一报文承载头的标识字段的值修 改为所述参数中 OFCS预期的承载类型的标识值。 可选地， 所述扩展动作还包括设置元数据字段， 所述设置元数据字段动 作包括以下参数： 字段偏移、 字段大小、 待设置值类型和数值；
所述第一单元设置成按照如下方式在第一报文中修改元数据： 将所述字 段偏移参数指向的元数据字段的数值设置为所述数值参数。
可选地， 所述开放流逻辑交换机还包括匹配单元， 其中：
所述接收单元还设置成： 接收 OF控制器下发第二流表条目， 该第二流 表条目的匹配域中包含扩展的元数据字段；
所述匹配单元设置成： 在流表管道的流表上釆用元数据的内容部分包含 的流分类标识字段作为匹配键值。
可选地， 所述开放流逻辑交换机还包括第二单元， 其中：
在所述第二流表条目的写-动作指令的动作参数集中包含扩展动作， 所述 扩展动作包括弹出元数据， 所述弹出元数据动作包括以下参数： 元数据的承 载类型和第二标识字段；
所述第二单元设置成： 从报文中剥离元数据， 并将元数据的内容部分的 第二标识字段的值回填报文的承载头的标识字段。
一种开放流能力交换机， 包括： 识别解析单元和引导单元， 其中： 所述识别解析单元设置成： 识别接收到的报文中携带的元数据， 解析元 数据的内容部分；
所述引导单元设置成： 将报文和 /或所述元数据的内容部分引导到所述开 放流能力交换机 OFCS上的逻辑服务节点进行处理。
可选地，所述识别解析单元设置成按照如下方式解析元数据的内容部分： 根据元数据内容部分中的第一标识字段指示的元数据的格式， 对元数据 内容部分进行解析。
可选地， 所述引导单元设置成按照如下方式将报文和 /或所述元数据的内 容部分引导到所述 OFCS上的逻辑服务节点：
在所述元数据的内容部分包含开放流逻辑交换机 OFLS标识字段时， 根 据所述 OFLS 标识字段确定将所述报文和 /或元数据的内容部分引导到的 OFLS; 或者，
在所述元数据的内容部分包含流分类标识字段时， 根据已配置的流映射 策略将所述报文和 /或元数据的内容部分引导到 OFLS上； 或者，
在所述元数据的内容部分包含服务节点标识字段时， 将所述报文和 /或元 数据的内容部分引导到服务节点标识字段指向的服务实例上。
综上所述， 上述技术方案通过在 OFLS之间传递的报文中携带元数据， 可以减少下一个 OFLS进行与上一个 OFLS相重复的工作， 从而节省部分资 源。 附图概述
图 1是相关技术中 OF-Config协议和 OpenFlow协议的示意图； 图 2是相关技术中基于每个流表的报文处理的示意图；
图 3是相关技术的报文流通过 OpenFlow处理管道的示意图；
图 4是本发明实施方式的传输元数据的方法的流程图；
图 5是本发明实施方式的信息配置方法的流程图；
图 6是本发明实施方式的接收元数据的方法的流程图；
图 7是根据本发明实施例的 metadata在 OFCS间传递的网络架构图； 图 8是根据本发明实施例的 metadata应用不同承载方式承载时的报文封 装格式；
图 9是根据本发明实施例的 metadata穿越三层网络的传递示例； 图 10是本发明实施方式的开放流逻辑交换机的架构图；
图 11是本发明实施方式的开放流能力交换机的架构图。 本发明的较佳实施方式 本申请中考虑到， 在多个 OFCS形成一个 SDN网络时， 例如针对流分类 等问题， 如果中间节点不能利用边缘节点的流分类处理的成果， 就需要消耗 更多的资源来重复进行流分类的工作， 所以本申请在 OFCS 间传递元数据 metadata,解决因中间节点不能利用边缘节点的流分类处理的成果， 需要消耗 更多的资源来重复进行流分类的工作的问题。
本申请中， 在转发节点间传输 metadata, 可以在 metadata无感知的中间 网络上携带 metadata进行交互， 携带彼此感兴趣的信息。
目前， 在 SDN网络中， 在转发节点间传递 metadata存在以下问题（传递 灵活、 有弹性的 metadata尤其如此） ， 因此目前并没有在转发节点间实现 metadata的传输：
( 1 )交换 metadata的两个 OFCS对于所处理的 metadata的理解无法达成 共识。
( 2 ) metadata不能被 OFCS的报文解析模块识别并解析。
( 3 ) metadata和 4艮文无法融为一体。
本发明实施例旨在解决上述问题， 提供 OFCS间传递 metadata的解决方 案。
如图 4所示， 本实施方式的传输元数据的方法， 包括：
步骤 401 :当前 OFCS上的开放流逻辑交换机 OFLS在第一报文中插入或 修改元数据， 生成携带元数据的第二报文；
其中， 所述第一报文是其他的逻辑题发送给当前 OFCS的。
步骤 402: 当前 OFCS根据与所述第二报文匹配的流表条目指示的动作 将第二报文传递给下一级 OFCS。 其中， 流表条目指： 在 OFCS中的 flow table中的流表项， 每一项称为一 个流表条目。
当前 OFCS和下一级 OFCS之间可以存在其他 OFCS或传统转发设备， 但中间的 OFCS 或传统转发设备应不感知或不关注在当前 OFCS 和下一级 OFCS之间传递报文所携带的元数据 metadata,例如这些中间的 OFCS或传统 转发设备仅关注 MAC头信息， 而报文携带的 metadata承载于 UDP层上。
元数据包含： 特性部分和内容部分； 特性部分包含： 携带元数据的第二 报文的传输方式信息和元数据的识别方式信息； 其中， 传输方式信息确定第 二报文传输元数据时的承载方式； 识别方式信息确定所述承载方式下 OFCS 预期的承载类型的标识值； 元数据的内容部分包含业务属性信息。
传输方式信息表示第二报文传输的元数据是承载于以太层， 识别方式信 息为 OFCS预期的以太类型的值； 或者， 传输方式信息表示第二报文传输的 元数据是承载于 IP层，识别方式信息为 OFCS预期的 IP协议类型的值；或者， 传输方式信息表示第二报文传输的元数据是承载于 UDP层，识别方式信息为 OFCS预期的 UDP目的端口类型的值。
SDN中的 OFCS支持多种不同格式的元数据， 元数据的内容部分包含第 一标识字段（metadata ID ) , 第一标识字段的值根据元数据的格式确定。 不 同元数据格式的元数据的内容部分包含一个或多个不同类型的字段。 第一标 识字段用于标识元数据釆用的格式。
元数据的内容部分包含第二标识字段， 在第二标识字段中保存插入 metadata前第一报文承载头的标识字段的值。在下一级 OFCS上的 0FLS剥离 metadata时， 可用 metadata中第二标识字段的值回填第二报文承载层的标识 字段。 例如， metadata承载于以太头上， 第一报文原始的以太头的以太类型 是 0x0800, 该 metadata预期的以太类型的值为 0xa811 , 则在第一报文上插入 metadata后， 以太头的以太类型为 0xa811 , metadata的第二标识字段和以太 类型大小保持一致， 填充的值为 0x0800; 在下一级 OFCS上的 0FLS 剥离 metadata时， 用 metadata的第二标识字段数值回填以太头的以太类型， 这样 以太头的以太类型恢复成 0x0800。
OF控制器根据业务部署的要求决定在当前 OFCS上的 0FLS和下一级
OFCS之间通过报文稍带 metadata时， 捎带的 metadata满足下一级 OFCS支 持的 metadata格式。
当前 OFCS上的 0FLS在第一报文中插入元数据之前， 包括： OFLS接收 OF控制器下发的第一流表条目， 第一流表条目用于处理一类 报文， 该第一流表条目的写-动作指令的动作参数集中包含扩展动作， 扩展动 作包括推入元数据（ push-metadata ) , 指示向流表条目匹配命中的报文的指 定位置插入 metadata, 推入元数据动作包括以下参数： 携带元数据的第二报 文的承载方式、 承载方式下 0FCS预期的承载类型的标识值和元数据的格式 标识 ( metadata ID ) ；
OFLS在第一报文中插入元数据， 包括：
0FLS将第一报文匹配到第一流表条目，根据参数中的承载方式在第一报 文中对应的位置插入 metadata ID指定格式的元数据的内容部分，在内容部分 的第二标识字段中写入第一报文承载头的标识字段的值， 然后将第一报文承 载头的标识字段的值修改为参数中 0FCS预期的承载类型的标识值。
扩展动作还包括设置元数据字段（set-metadata-field ) , 设置元数据字段 动作包括以下参数： 字段偏移、 字段大小、 待设置值类型和数值；
OFLS在第一报文中修改元数据， 包括：
OFLS将所述字段偏移参数指向的元数据字段的数值设置为数值参数。
如图 5所示， 本实施方式还提供了一种信息配置方法， 应用于 SDN, 包 括：
步骤 501 : SDN中的 0FCS接收第一节点对元数据格式的配置； 步骤 502: 0FCS上的 OFLS接收所述第一节点对 OFLS绑定的元数据格 式的配置。
第一节点包括： OF配置点、 OF控制器、 网络管理系统 NMS和 0FCS 本地。
0FCS对上述来源的 metadata格式的配置进行检查， 当发现配置错误或 不能识别解析 metadata格式时， 回应配置错误信息。
在所述绑定的元数据格式由所述 OF配置点、 网络管理系统或 0FCS本 地配置时， 所述方法还包括： OFLS向与该 OFLS建链的 OF控制器上报该 OFLS绑定的元数据格式。 OFLS向与该 OFLS建链的 OF控制器上报该 OFLS绑定的元数据格式， 包括： OFLS通过扩展的专用异步消息将绑定的元数据格式主动上报给建链的 OF控制器； 或者， OFLS与 OF控制器之间通过 Multipart消息中扩展的一组 元数据格式查询请求消息和元数据格式查询应答消息， 进行 OFLS绑定的元 数据格式的查询和上报。
如图 6所示，本实施方式还提供了一种接收元数据的方法，应用于 SDN, 包括：
步骤 601 : SDN中的 OFCS接收到报文后， 识别报文中携带的元数据， 解析元数据的内容部分；
步骤 602: OFCS将报文和 /或元数据的内容部分引导到 OFCS上的逻辑 服务节点进行处理。
OFCS解析元数据的内容部分， 包括： OFCS根据元数据内容部分中的第 一标识字段指示的元数据的格式， 对元数据内容部分进行解析。
OFCS将报文和 /或元数据的内容部分引导到 OFCS上的逻辑服务节点， 包括： OFCS在元数据的内容部分包含 OFLS标识（OFLS-ID )字段时， 根据 OFLS标识字段确定将报文和 /或元数据的内容部分引导到的 OFLS; 或者，
OFCS在元数据的内容部分包含流分类标识（Flow-ID )字段时， 根据已 配置的流映射策略将所述 文和 /或元数据的内容部分引导到 OFLS上；或者， OFCS在元数据的内容部分包含服务节点标识（ Server-node-ID )字段时， 将所述报文和 /或元数据的内容部分引导到服务节点标识字段指向的服务实 例上。
逻辑服务节点进行处理之前， 包括：
逻辑服务节点接收 OF控制器下发第二流表条目，用于处理上一级 OFCS 上的 OFLS传递过来的携带 metadata的报文， 该第二流表条目的匹配域中包 含扩展的元数据字段做匹配键值， 例如 metadata-field [id] , 该 ID为 metadata 的字段标识；
逻辑服务节点进行处理， 包括： 逻辑服务节点在流表管道的流表 （该流表的条目 匹配域包括匹配 metadata 的流分类标识字段） 上釆用元数据的内容部分包含的流分类标识 ( Flow-ID )字段作为匹配键值。
在第二流表条目的写-动作指令的动作参数集中包含扩展动作： 弹出元数 据（ pop-metadata ) , 弹出元数据动作包括以下参数： 元数据的承载类型和第 二标识字段；
逻辑服务节点进行处理， 还包括：
逻辑服务节点从报文中剥离元数据， 并将元数据的内容部分的第二标识 字段的值回填报文的承载头的标识字段。
下面将结合附图和实施例对本发明进行详细描述。
实施例 1 :
实施例 1是根据本发明的 metadata定义的 XML示例。 metadata定义包含 feature和 content两部分：
feature表示定义传输或 i只另1 J metadata的方式： 口示例 ( 1 )表示 metadata 承载于以太上；可选地，在 feature域中还可指定由 metadata封装的报文类型， 如示例 （1 ) 中设置由 metadata封装的报文类型为 ethertype。 示例 （2 )表示 metadata 载于 IP上； 示例 （ 3 )表示 metadata 载于 UDP上。
content是 metadata的正文， 一般建议第一个 IByte定义为 metadata格式 ID (即每种 feature类型 metadata最多可以定义 256种格式 ) ； 第二个 IByte 定义为 metadata 的长度， metadata 长度不超过 64Byte； 其他字段均以 <size,name>二元组的方式定义。
( 1 )
<metadata>
<feature>
<type>ether<type>; 载层为以太头
<value>0xa811 </value>； 识别 metadata的以太类型为 0xa811 </feature>
<content>
<field>
<size>8bit</size>; 该字段长度为 8bit
<name>id</name>; 该字段名称 ID， 该 ID表示 metadata类型的 ID
</field>
<field>
<size>8bit</size>
<name>length</name>
</field>
<field>
<size>32bit</size>
<name>flow-id</name>； 流分类标识
</field>
<field>
<size> 16bit</size>
<name> etherType </name>; 保存插入 metadata前原以太头的以太类型 字段的值
</field>
<content>
</metadata>
( 2 )
<metadata>
<feature> <type>ip<type>; 承载层为 IP头
<value>0x0a47</value>； 识别 metadata的 IP头协议类型为 0x0a47 </feature>
<content>
<field>
<size>8bit</ size>
<name>id</name>； metadata格式的 ID
</field>
<field>
<size>8bit</size>
<name>length</name>
</field>
<field>
<size>32bit</ size>
<name> OFLS-id</name>; OFLS的唯一标识
</field>
<field>
<size> 16bit</ size>
<name> protocol-type </name>;保存插入 metadata前原 IP头的协议类型 字段的值
</field>
<content>
</metadata> ( 3 ) <metadata>
<feature>
<type>udp<type>; 7?i载层为 UDP头
<value>0x6047</value>； 识别 metadata的 UDP头目的端口为 0x6047
</feature>
<content>
<field>
<size>8bit</ size>
<name>id</name>； 表示 metadata类型的 ID
</field>
<field>
<size>8bit</ size>
<name>length</name>
</field>
<field>
<size>32bit</ size>
<name> service-node-id </name>
</field>
<field>
<size> 16bit</ size>
<name>udp-dport</name>； 保存插入前原 UDP头的目的端口字段的值
</field>
<content>
</metadata> 实施例 2: 实施例 2是根据本发明扩展的 OF controller对 OFLS的流表的 action动作： metadata ^ push-metadata、 pop-metadata和 set-metadata-field动作。
push metadata <type> <value> <id> pop metadata <type> <id> type表示 metadata的特征类型， 取值为
enum
1、 {
ETHER— TYPE, IP— PROTOCOL, UDP DPORT, TCP DPORT
size表示 metadata的空间大小；
value表示 metadata的特征值。
set metadata <offset> <size> <source-type> <target-value> offset表示选定字段相对于 metadata内容起始位置的偏移， 以 Byte为单 位。
size表示选定字段的大小。 source-type表示 metadata的内容字段数据来源类型， 取值为
enum
FIX, PACKET, LOCAL, METADATA
其中：
FIX表示该值由控制器设定， 即将 target-value写入指定的偏移位置。 PACKET表示该值来自报文的某个字段， 该取值的字段由控制器设定。
LOCAL表示该值由 OFLS转发面本地产生， 例如 32bit的随机值或 64bit 的时间戳（或格式化的时间戳） 。
METADATA表示该值来自上一级 OFLS传递来的 metadata中的某一字 段。
target-value:表示待填充到选定字段上的值，可以是控制器设置的固定值， 也可以是控制器指定的收到报文的某个设定字段的值。
实施例 3:
实施例 3是根据本发明的 metadata在 OFCS上做流映射策略的操作示例。 当前 OFCS接收上一级 OFCS上的 OFLS传递来的携带 metadata的报文 后， 才艮据约定的 metadata的格式， 读取 metadata的 content (如 OFLS-id ) , 并进行相应的操作。
假设 OFCS的可编程报文解析模块识别并解析的 metadata ,获知 OFLS-id 字段的值（例如该值对应 OFLS1 ) , 然后由映射模块根据该 OFLS-id字段的 值将所述>¾文引导到 OFLS1进行流表管道的处理。
实施例 4:
实施例 4是根据本发明的 metadata在 OFCS间传递的网络架构图 （如图 7所示） 。
OpenFlow边缘转发节点收到来自传统网络的报文， 经过本地处理后， 生 成 metadata , 并按照约定的 metadata的格式， PDU使用 metadata进行封装， 然后承载在 L2/L3/L4传输协议上进行传输。 可选地， 当另一 OpenFlow边缘转发节点收到来自 OpenFlow网络的报文 时， 按照约定的 metadata的格式， 从报文中剥离 metadata, 然后发送给传统 网络的转发设备。
实施例 5:
如图 8所示， 实施例 5是根据本发明的 metadata应用不同承载方式承载 时的报文封装格式。
当 metadata使用以太进行 载时， 设置才艮文的 Ethertype头的 Ethertype 为 Oxyyyy, 表示 metadata使用以太进行 装。
当 metadata使用 IP进行承载时，设置报文的 IP头的 Protocol Type为 χχχ , 表示 metadata使用 IP进行封装。
当 metadata使用 UDP进行承载时，设置报文的 UDP头的 Dport为 xxxxx, 表示 metadata使用 UDP进行封装。
实施例 6:
如图 9所示， 实施例 6是根据本发明的 metadata穿越三层网络的传递示 例。
OpenFlow边缘转发节点收到来自 OpenFlow 网络的报文后， 若携带了 metadata,则才艮据约定的 metadata的格式，读取 metadata 1的 content( ^口 flow-id、 next-OFLS-id、 dpi-instance-id等） ， 并进行相应的操作。
OpenFlow 边缘转发节点将经过本地处理后生成的 metadata2 , 按模拟 VXLAN隧道的方式， 将 metadata2承载在模拟 VXLAN隧道的外层 UDP头 上进行传输， 同时设置 UDP的目的 port为 zzzzz。
可选地， PDU由 VLAN (可选） 、 Ethernet封装， 然后再由 metadata2封 装。 所述报文封装完成后发送给对端 OpenFlow边缘转发节点。
当对端 OpenFlow边缘转发节点收到此报文后，按模拟 VXLAN隧道的方 式从报文中剥离 metadata2、 并同步在该模拟 VXLAN隧道的虚接口上剥离外 层 UDP头、 IP头、 以太头等封装， 获得租户的原始二层报文， 并对报文进行 相应的处理。经过本地处理后，若生成新的 metadata3 ,则按照约定的 metadata 的定义， 即 PDU使用 metadata3进行封装， 然后承载在 L2传输协议上进行 传输。
如图 10所示， 本实施方式提供了一种开放流逻辑交换机， 包括： 第一单 元 1001 , 其中：
第一单元 1001设置成： 在第一报文中插入或修改元数据， 生成携带元数 据的第二报文。 元数据包含： 特性部分和内容部分；
特性部分包含： 携带元数据的第二报文的传输方式信息和元数据的识别 方式信息； 其中， 传输方式信息确定第二报文传输元数据时的承载方式； 识 别方式信息确定承载方式下开放流能力交换机 OFCS预期的承载类型的标识 值；
元数据的内容部分包含业务属性信息。
元数据的内容部分包含第一标识字段， 第一标识字段的值根据元数据的 格式确定； 元数据的内容部分还包含第二标识字段， 在第二标识字段中保存 第一报文承载头的标识字段的值。
传输方式信息表示第二报文传输元数据时承载于以太层， 识别方式信息 为 OFCS预期的以太类型的值； 或者， 传输方式信息表示第二报文传输元数 据时承载于 IP层， 识别方式信息为 OFCS预期的 IP协议类型的值； 或者， 传 输方式信息表示第二报文传输元数据时承载于 UDP层， 识别方式信息为 OFCS预期的 UDP目的端口类型的值。
开放流逻辑交换机还包括接收单元 1002 , 其中：
接收单元 1002设置成： 接收 OF控制器下发的第一流表条目， 该第一流 表条目的写-动作指令的动作参数集中包含扩展动作： 推入元数据， 推入元数 据动作包括以下参数：携带元数据的第二报文的承载方式、承载方式下 OFCS 预期的承载类型的标识值和元数据的格式标识； 第一单元 1001设置成按照如下方式在第一报文中插入元数据：将第一报 文匹配到第一流表条目， 根据参数中的承载方式在第一报文中对应的位置插 入元数据的内容部分， 在内容部分的第二标识字段中写入第一报文承载头的 标识字段的值， 然后将第一报文承载头的标识字段的值修改为参数中 OFCS 预期的承载类型的标识值。 扩展动作还包括： 设置元数据字段，设置元数据字段动作包括以下参数： 字段偏移、 字段大小、 待设置值类型和数值；
第一单元设置成按照如下方式在第一报文中修改元数据： 将字段偏移参 数指向的元数据字段的数值设置为数值参数。
开放流逻辑交换机还包括匹配单元 1003 , 其中：
接收单元 1002还设置成： 接收 OF控制器下发第二流表条目， 该第二流 表条目的匹配域中包含扩展的元数据字段； 匹配单元 1003设置成：在流表管道的流表上釆用元数据的内容部分包含 的流分类标识字段作为匹配键值。
开放流逻辑交换机还包括第二单元 1004, 其中： 在第二流表条目的写-动作指令的动作参数集中包含扩展动作： 弹出元数 据， 弹出元数据动作包括以下参数： 元数据的承载类型和第二标识字段； 第二单元 1004设置成： 从报文中剥离元数据， 并将元数据的内容部分的 第二标识字段的值回填报文的承载头的标识字段。
如图 11所示， 本实施方式还提供了一种开放流能力交换机， 包括： 识别 解析单元 1101和引导单元 1102, 其中： 识别解析单元 1101设置成： 识别接收到的报文中携带的元数据， 解析元 数据的内容部分；
引导单元 1102设置成： 报文和 /或元数据的内容部分引导到开放流能力 交换机 OFCS上的逻辑服务节点进行处理。
识别解析单元 1101设置成按照如下方式解析元数据的内容部分：根据元 数据内容部分中的第一标识字段指示的元数据的格式， 对元数据内容部分进 行解析。
引导单元 1102设置成按照如下方式将报文和 /或元数据的内容部分引导 到 OFCS上的逻辑服务节点：
在元数据的内容部分包含开放流逻辑交换机 OFLS 标识字段时， 根据
OFLS标识字段确定将报文和 /或元数据的内容部分引导到的 OFLS; 或者， 在元数据的内容部分包含流分类标识字段时， 根据已配置的流映射策略 将报文和 /或元数据的内容部分引导到 OFLS上； 或者，
在元数据的内容部分包含服务节点标识字段时， 将报文和 /或元数据的内 容部分引导到服务节点标识字段指向的服务实例上。
本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序 来指令相关硬件完成， 所述程序可以存储于计算机可读存储介质中， 如只读 存储器、 磁盘或光盘等。 可选地， 上述实施例的全部或部分步骤也可以使用 一个或多个集成电路来实现， 相应地， 上述实施例中的各模块 /单元可以釆用 硬件的形式实现， 也可以釆用软件功能模块的形式实现。 本申请不限制于任 何特定形式的硬件和软件的结合。
以上所述仅为本申请的优选实施例而已， 并不用于限制本申请， 对于本 领域的技术人员来说， 本申请可以有各种更改和变化。 凡在本申请的精神和 原则之内， 所作的任何修改、 等同替换、 改进等， 均应包含在本申请的保护 范围之内。
工业实用性
综上所述， 上述技术方案通过在 OFLS之间传递的报文中携带元数据， 可以减少下一个 OFLS进行与上一个 OFLS相重复的工作， 从而节省部分资 源。 因此本发明具有很强的工业实用性。

Claims

权 利 要 求 书
1、 一种传输元数据的方法， 应用于软件定义网络 SDN, 该方法包括： 当前开放流能力交换机 OFCS上的开放流逻辑交换机 OFLS在第一报文 中插入或修改元数据， 生成携带所述元数据的第二报文；
当前 OFCS根据与所述第二报文匹配的流表条目指示的动作将所述第二 报文传递给下一级 0FCS。
2、 如权利要求 1所述的传输元数据的方法， 其中：
所述元数据包含： 特性部分和内容部分；
所述特性部分包含： 携带所述元数据的所述第二报文的传输方式信息和 所述元数据的识别方式信息； 其中， 所述传输方式信息用于确定第二报文传 输元数据时的承载方式； 所述识别方式信息用于确定所述承载方式下 OFCS 预期的承载类型的标识值；
所述元数据的内容部分包含业务属性信息。
3、 如权利要求 2所述的传输元数据的方法， 其中：
所述传输方式信息表示所述第二报文传输的元数据承载于以太层， 所述 识别方式信息为 OFCS预期的以太类型的值； 或者，
所述传输方式信息表示所述第二报文传输的元数据承载于 IP层， 所述识 别方式信息为 OFCS预期的 IP协议类型的值； 或者，
所述传输方式信息表示所述第二报文传输的元数据承载于 UDP层，所述 识别方式信息为 OFCS预期的 UDP目的端口类型的值。
4、 如权利要求 2或 3所述的传输元数据的方法， 其中：
所述 SDN中的 OFCS支持多种不同格式的元数据，所述元数据的内容部 分包含第一标识字段， 所述第一标识字段的值根据所述元数据的格式确定。
5、 如权利要求 4所述的传输元数据的方法， 其中：
所述元数据的内容部分包含第二标识字段， 在所述第二标识字段中保存 所述第一报文承载头的标识字段的值。
6、 如权利要求 5所述的传输元数据的方法， 其中， 所述 OFLS在第一报 文中插入元数据之前， 该方法还包括：
所述 OFLS接收 OF控制器下发的第一流表条目， 该第一流表条目的写- 动作指令的动作参数集中包含扩展动作， 所述扩展动作包括推入元数据， 所 述推入元数据动作包括以下参数： 携带元数据的第二报文的承载方式、 所述 承载方式下 OFCS预期的承载类型的标识值和所述元数据的格式标识；
所述 OFLS在第一报文中插入元数据的步骤包括：
所述 OFLS将所述第一报文匹配到所述第一流表条目， 根据所述参数中 的承载方式在第一报文中对应的位置插入所述元数据的内容部分， 在内容部 分的第二标识字段中写入第一报文承载头的标识字段的值， 然后将第一报文 承载头的标识字段的值修改为所述参数中 0FCS预期的承载类型的标识值。
7、 如权利要求 6所述的传输元数据的方法， 其中：
所述扩展动作还包括设置元数据字段， 所述设置元数据字段动作包括以 下参数： 字段偏移、 字段大小、 待设置值类型和数值；
所述 OFLS在第一报文中修改元数据的步骤包括：
所述 OFLS将所述字段偏移参数指向的元数据字段的数值设置为所述数 值参数。
8、 一种信息配置方法， 应用于软件定义网络 SDN, 该方法包括： 所述 SDN中的开放流能力交换机 0FCS接收第一节点对元数据格式的配 置；
所述 0FCS上的开放流逻辑交换机 OFLS接收所述第一节点对所述 OFLS 绑定的元数据格式的配置。
9、 如权利要求 8所述的信息配置方法， 其中：
所述第一节点包括： OF配置点、 OF控制器、网络管理系统 NMS和 0FCS 本地；
在所述绑定的元数据格式由所述 OF配置点、 网络管理系统或 OFCS本 地配置时， 所述方法还包括： 所述 OFLS向与该 OFLS建链的 OF控制器上才艮 该 OFLS绑定的元数据格式。
10、 如权利要求 9所述的信息配置方法， 其中， 所述 OFLS向与该 OFLS 建链的 OF控制器上报该 OFLS绑定的元数据格式的步骤包括：
所述 OFLS通过扩展的专用异步消息将绑定的元数据格式主动上报给所 述建链的 OF控制器。
11、 如权利要求 9所述的信息配置方法， 其中， 所述 OFLS向与该 OFLS 建链的 OF控制器上报该 OFLS绑定的元数据格式的步骤包括：
所述 OFLS与 OF控制器之间通过 Multipart消息中扩展的一组元数据格 式查询请求消息和元数据格式查询应答消息， 进行 OFLS绑定的元数据格式 的查询和上才艮。
12、 一种接收元数据的方法， 应用于软件定义网络 SDN, 该方法包括： 所述 SDN中的开放流能力交换机 OFCS接收到报文后，识别报文中携带 的元数据， 解析元数据的内容部分， 将报文和 /或所述元数据的内容部分引导 到所述 OFCS上的逻辑服务节点进行处理。
13、 如权利要求 12所述的接收元数据的方法， 其中， 所述 OFCS解析元 数据的内容部分的步骤包括：
所述 OFCS 根据元数据内容部分中的第一标识字段指示的元数据的格 式， 对元数据内容部分进行解析。
14、 如权利要求 13所述的接收元数据的方法， 其中， 所述 OFCS将报文 和 /或所述元数据的内容部分引导到所述 OFCS 上的逻辑服务节点的步骤包 括：
所述 OFCS在所述元数据的内容部分包含开放流逻辑交换机 OFLS标识 字段时， 根据所述 OFLS标识字段确定将所述报文和 /或元数据的内容部分引 导到的 OFLS; 或者，
所述 OFCS在所述元数据的内容部分包含流分类标识字段时， 根据已配 置的流映射策略将所述"¾文和 /或元数据的内容部分引导到 OFLS上； 或者， 所述 OFCS在所述元数据的内容部分包含服务节点标识字段时， 将所述 报文和 /或元数据的内容部分引导到服务节点标识字段指向的服务实例上。
15、 如权利要求 12所述的接收元数据的方法， 其中， 所述逻辑服务节点 进行处理之前， 该方法还包括：
所述逻辑服务节点接收 OF控制器下发第二流表条目， 该第二流表条目 的匹配域中包含扩展的元数据字段；
所述逻辑服务节点进行处理的步骤包括：
所述逻辑服务节点在流表管道的流表上釆用元数据的内容部分包含的流 分类标识字段作为匹配键值。
16、 如权利要求 15所述的接收元数据的方法， 其中：
在所述第二流表条目的写 -动作指令的动作参数集中包含扩展动作， 所述 扩展动作包括弹出元数据， 所述弹出元数据动作包括以下参数： 元数据的承 载类型和第二标识字段；
所述逻辑服务节点进行处理的步骤还包括：
所述逻辑服务节点从报文中剥离元数据， 并将元数据的内容部分的第二 标识字段的值回填报文的承载头的标识字段。
17、 一种开放流逻辑交换机， 包括： 第一单元， 其中：
所述第一单元设置成： 在第一报文中插入或修改元数据， 生成携带所述 元数据的第二报文。
18、 如权利要求 17所述的开放流逻辑交换机， 其中：
所述元数据包含： 特性部分和内容部分； 所述特性部分包含： 携带元数据的第二报文的传输方式信息和元数据的 识别方式信息； 其中， 所述传输方式信息确定第二报文传输元数据时的承载 方式； 所述识别方式信息确定所述承载方式下开放流能力交换机 OFCS预期 的承载类型的标识值；
所述元数据的内容部分包含业务属性信息。
19、 如权利要求 18所述的开放流逻辑交换机， 其中： 所述元数据的内容部分包含第一标识字段， 所述第一标识字段的值根据 所述元数据的格式确定； 所述元数据的内容部分还包含第二标识字段， 在所 述第二标识字段中保存所述第一报文承载头的标识字段的值。
20、如权利要求 19所述的开放流逻辑交换机， 所述开放流逻辑交换机还 包括接收单元， 其中： 所述接收单元设置成： 接收 OF控制器下发的第一流表条目， 该第一流 表条目的写-动作指令的动作参数集中包含扩展动作， 所述扩展动作包括推入 元数据， 所述推入元数据动作包括以下参数： 携带元数据的第二报文的承载 方式、 所述承载方式下 OFCS预期的承载类型的标识值和所述元数据的格式 标识；
所述第一单元设置成按照如下方式在第一报文中插入元数据： 将所述第 一报文匹配到所述第一流表条目， 根据所述参数中的承载方式在第一报文中 对应的位置插入所述元数据的内容部分， 在内容部分的第二标识字段中写入 第一报文承载头的标识字段的值， 然后将第一报文承载头的标识字段的值修 改为所述参数中 OFCS预期的承载类型的标识值。
21、 如权利要求 20所述的开放流逻辑交换机， 其中： 所述扩展动作还包括设置元数据字段， 所述设置元数据字段动作包括以 下参数： 字段偏移、 字段大小、 待设置值类型和数值；
所述第一单元设置成按照如下方式在第一报文中修改元数据： 将所述字 段偏移参数指向的元数据字段的数值设置为所述数值参数。
22、 如权利要求 20或 21所述的开放流逻辑交换机， 所述开放流逻辑交 换机还包括匹配单元， 其中：
所述接收单元还设置成： 接收 OF控制器下发第二流表条目， 该第二流 表条目的匹配域中包含扩展的元数据字段；
所述匹配单元设置成： 在流表管道的流表上釆用元数据的内容部分包含 的流分类标识字段作为匹配键值。
23、 如权利要求 22所述的开放流逻辑交换机， 其中， 所述开放流逻辑交 换机还包括第二单元， 其中：
在所述第二流表条目的写-动作指令的动作参数集中包含扩展动作， 所述 扩展动作包括弹出元数据， 所述弹出元数据动作包括以下参数： 元数据的承 载类型和第二标识字段；
所述第二单元设置成： 从报文中剥离元数据， 并将元数据的内容部分的 第二标识字段的值回填报文的承载头的标识字段。
24、 一种开放流能力交换机， 包括： 识别解析单元和引导单元， 其中： 所述识别解析单元设置成： 识别接收到的报文中携带的元数据， 解析元 数据的内容部分；
所述引导单元设置成： 将报文和 /或所述元数据的内容部分引导到所述开 放流能力交换机 OFCS上的逻辑服务节点进行处理。
25、 如权利要求 24所述的开放流能力交换机， 其中， 所述识别解析单元 设置成按照如下方式解析元数据的内容部分： 根据元数据内容部分中的第一标识字段指示的元数据的格式， 对元数据 内容部分进行解析。
26、 如权利要求 24所述的开放流能力交换机， 其中， 所述引导单元设置 成按照如下方式将报文和 /或所述元数据的内容部分引导到所述 OFCS上的逻 辑服务节点：
在所述元数据的内容部分包含开放流逻辑交换机 OFLS标识字段时， 根 据所述 OFLS 标识字段确定将所述报文和 /或元数据的内容部分引导到的 OFLS; 或者，
在所述元数据的内容部分包含流分类标识字段时， 根据已配置的流映射 策略将所述报文和 /或元数据的内容部分引导到 OFLS上； 或者，
在所述元数据的内容部分包含服务节点标识字段时， 将所述报文和 /或元 数据的内容部分引导到服务节点标识字段指向的服务实例上。
PCT/CN2014/080387 2013-08-30 2014-06-20 一种传输、接收元数据的方法、开放流逻辑交换机 WO2015027738A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201310389058.5A CN104426762A (zh) 2013-08-30 2013-08-30 一种传输、接收元数据的方法、开放流逻辑交换机
CN201310389058.5 2013-08-30

Publications (1)

Publication Number Publication Date
WO2015027738A1 true WO2015027738A1 (zh) 2015-03-05

Family

ID=52585511

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2014/080387 WO2015027738A1 (zh) 2013-08-30 2014-06-20 一种传输、接收元数据的方法、开放流逻辑交换机

Country Status (2)

Country Link
CN (1) CN104426762A (zh)
WO (1) WO2015027738A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104717683B (zh) * 2015-03-26 2018-05-29 清华大学 一种基于软件定义网络南向接口协议的用户请求处理方法
CN106470168B (zh) * 2015-08-22 2019-12-06 华为技术有限公司 一种数据传输方法、使用该方法的交换机以及网络控制系统
CN108259354B (zh) * 2018-01-10 2021-02-26 浙江工商大学 一种基于匹配字段间逻辑关系的多级流表设计方法
CN108259353B (zh) * 2018-01-10 2021-02-26 浙江工商大学 一种基于匹配字段具体值重复率的多级流表设计方法
CN109600318B (zh) * 2018-11-29 2022-07-12 新华三技术有限公司合肥分公司 一种监控sdn中应用程序的方法及sdn控制器
CN110958194A (zh) * 2019-11-29 2020-04-03 浪潮云信息技术有限公司 一种OpenFlow交换机的报文处理方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102957603A (zh) * 2012-11-09 2013-03-06 盛科网络（苏州）有限公司 基于多级流表的Openflow报文转发方法及系统
CN103051629A (zh) * 2012-12-24 2013-04-17 华为技术有限公司 一种基于软件定义网络中数据处理的系统、方法和节点

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8873398B2 (en) * 2011-05-23 2014-10-28 Telefonaktiebolaget L M Ericsson (Publ) Implementing EPC in a cloud computer with openflow data plane
CN103181129B (zh) * 2011-10-25 2015-09-30 华为技术有限公司 数据报文处理方法和系统、报文转发设备
US8441961B1 (en) * 2012-12-24 2013-05-14 Sideband Networks, Inc. Metadata-driven switch network control
CN103067245B (zh) * 2012-12-28 2015-10-28 中兴通讯股份有限公司 一种用于网络虚拟化的流表空间隔离装置及方法
CN103200086B (zh) * 2013-03-12 2015-08-19 浙江工商大学 一种ForCES系统中路由协议的信息交互方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102957603A (zh) * 2012-11-09 2013-03-06 盛科网络（苏州）有限公司 基于多级流表的Openflow报文转发方法及系统
CN103051629A (zh) * 2012-12-24 2013-04-17 华为技术有限公司 一种基于软件定义网络中数据处理的系统、方法和节点

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"OpenFlow Switch Specification Version 1.3.2", OPEN NETWORKING FOUNDATION, 25 April 2013 (2013-04-25), Retrieved from the Internet <URL:https://www.opennetworking.org/imagcs/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-vl.3.2.pdf> [retrieved on 20140818] *
"OpenFlow Switch Specification Version 1.3.2", OPEN NETWORKING FOUNDATION, 25 April 2013 (2013-04-25), Retrieved from the Internet <URL:https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.2.pdf> [retrieved on 20140818] *

Also Published As

Publication number Publication date
CN104426762A (zh) 2015-03-18

Similar Documents

Publication Publication Date Title
CN109218178B (zh) 一种报文处理方法及网络设备
US9699105B2 (en) Self-routing multicast in a software defined network fabric
US7783733B1 (en) Method and apparatus for dynamic configuration management
WO2017156974A1 (zh) 一种信息传输方法、装置和系统
EP3863237A1 (en) Packet forwarding method, packet transmission device, and packet reception device
WO2015027738A1 (zh) 一种传输、接收元数据的方法、开放流逻辑交换机
EP2843906B1 (en) Method, apparatus, and system for data transmission
US8010696B2 (en) Passing information from a forwarding plane to a control plane
CN112565046B (zh) 同步多播路由器能力
CN101136730A (zh) 一种分布式网络设备中的可靠同步方法
CN101355487B (zh) 一种标签分发方法及装置
WO2020168854A1 (zh) 一种evpn组播方法、装置及系统
WO2018072732A1 (zh) 一种信息处理方法、装置和计算机存储介质
CN108964940A (zh) 消息发送方法及装置、存储介质
US20060215653A1 (en) Encapsulating packets for network chip conduit port
WO2022021818A1 (zh) 数据报文的处理方法及装置、存储介质、电子装置
WO2014198217A1 (zh) 一种隧道处理方法及系统、控制面设备、转发面设备
EP3866391B1 (en) Controlling protocol independent multicast (pim) join/prune messages from a downstream pim neighbor using a pim join/prune response(s) from an upstream pim neighbor
WO2021093463A1 (zh) 报文转发的方法、第一网络设备以及第一设备组
WO2012119372A1 (zh) 一种报文处理方法、设备和系统
CN105681223A (zh) 一种sdn的数据包转发方法及装置
CN113765809A (zh) Bier组播流量的统计方法、设备以及系统
EP3913865B1 (en) Message decapsulation method and device, message encapsulation method and device, electronic device, and storage medium
WO2021164245A1 (zh) 负载分担的方法、第一网络设备
Cisco Configuring the Catalyst 8500 Software

Legal Events

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

Ref document number: 14840120

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14840120

Country of ref document: EP

Kind code of ref document: A1