MXPA05011579A - Source identifier for mac address learning - Google Patents

Source identifier for mac address learning

Info

Publication number
MXPA05011579A
MXPA05011579A MXPA/A/2005/011579A MXPA05011579A MXPA05011579A MX PA05011579 A MXPA05011579 A MX PA05011579A MX PA05011579 A MXPA05011579 A MX PA05011579A MX PA05011579 A MXPA05011579 A MX PA05011579A
Authority
MX
Mexico
Prior art keywords
station
data
source
identifier
originating
Prior art date
Application number
MXPA/A/2005/011579A
Other languages
Spanish (es)
Inventor
Regan Joe
W Tingle Nicholas
Original Assignee
Alcatel Ip Networks Inc
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 Alcatel Ip Networks Inc filed Critical Alcatel Ip Networks Inc
Publication of MXPA05011579A publication Critical patent/MXPA05011579A/en

Links

Abstract

A header value or label, referred to herein as a source station identification (SSID), is added to an encapsulated packet header, such as by adding the SSID as a label to the bottom of a stack of MPLS labels. The SSID comprises a unique identifier that identifies the PE that originated the packet. In some embodiments, the IP address of the originating PE may be used as the SSID for that PE. The PE receiving this packet can then associate the source Ethernet MAC address of received TLS traffic, e.g., with the originating PE. Given the SSID of the originating PE, the receiving PE is able to determine which LSP to use to send Ethernet traffic to the station with the learned MAC address.

Description

IDE SOURCE TYPICATOR FOR MAC ADDRESS LEARNING Field of the Invention The present invention relates, in general, to the routing of data and networks. More specifically, a source identifier for MAC address learning is described through a multi-point-to-point switched tag path. Background of the Invention Organizations and companies generate significant revenues by providing data communication services based on quality of service (QoS), which has become an important measure on which billing is based. In order to improve or maintain QoS, services such as leased lines, virtual leased lines (VLLs), virtual private networks (VPNs), the virtual private services of local area network (LAN) (VPLS) and others provide dedicated data communication systems. These systems provide a "dedicated" path tunnel, which can be a virtual circuit (VC) for data communication between two or more client networks that are not locally connected. A common procedure is to define the switched or changed label paths (LSPs) through which traffic can be directed to a particular destination or Ref.:167878 set of destinations served by a particular provider connection (PE) router. Where multiple locations may be necessary to be able to send traffic to the destination, a multi-point-to-point LSP can be defined (sometimes referred to in this document by the abbreviation "MP2P"). In MPLS (that is, the switching or label change of multiple protocols), an LSP is commonly MP2P. LSPs can also be used for point-to-point (P2P) applications and typically originate from the use of tag change and the unidirectional nature of LSPs. In this LSP MP2P, a plurality of defined paths of the originating PEs associated with the entry tunnel endpoints converge on a single path that enters the destination EP. However, a problem is generated because the destination PE must have a learning mode of the identity of the originating PE and the association that PE with the source MAC address of a received packet, for example, in order to know as Route the traffic sent to this source MAC address. When MPLS or MPLS versions of existing protocols (for example, RSVP-TE, LDP, MP-BGP, etc.) are used to implement LSP, the destination PE (reception) has no way of knowing which PE originated the packet, since each node along the the LSP uses its own label to send the packets to the next node, with the result that the receiving PE can identify through the primary label only the central or core device that sent the packet to the receiving PE along the last way • or section of the LSP. Conventional multi-point-to-point implementations require overlays or virtual tunnel linings to solve this problem. In particular, in a common procedure, a separate VC label is assigned by source EP for each service. In general, the common procedure solves a problem of source identification and traffic multiplexing for different VPNs using the same transport. However, this does not reduce the number of labels. This procedure is disadvantageous due to the overload and complexity associated with the allocation, handling and routing of packets that use a large number of labels. To quantify the drawback, if a separate VC label was assigned for each of the PE "n" devices or nodes associated with a particular customer or service, for example, the number of labels per service would be in the order of n2 (specifically, n (nl)), so that each node would require having a separate virtual circuit point-to-point in each other node. By contrast, if the destination PE had a way to identify the originating PE without requiring that a separate VC label be assigned for each PE for each service, each of the PE n devices would only require one label per service, so that only labels would be required. In this way, it would be useful for a solution to resolve such as determining a source station address without creating an additional layer or mesh of tunnels for an MP2P LSP. Brief Description of the Figures Various embodiments of the invention are described in the following detailed description and the accompanying figures. Figure 1A illustrates a system for learning a MAC address; Figure IB illustrates a system for learning a MAC address, which shows an FIB; Figure 2 illustrates a sample packet header that includes a source identifier for learning a MAC address; and Figure 3 illustrates a process for associating an identifier with a source MAC address. Detailed Description of the Invention The invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, a susceptible through computer as a means of storable be read be read by computer or a computer network, where the program instructions are sent through optical or electronic communication links. In this specification, these implementations or any other form that the invention could take, could be referred to as techniques. In general, the order of the stages of the described processes could be altered within the scope of the invention. The detailed description of one or more embodiments of the invention is provided below along with the accompanying figures, which illustrate the principles of the invention. The invention is described in connection with these embodiments, although the invention is not limited to any modality The scope of the invention is limited only by the claims and the invention includes numerous alternatives, modifications and equivalents.The numerous specific details are pointed out in The following description for the purpose of providing a complete understanding of the invention, these details are provided for the purpose of example and the invention could be implemented in accordance with the claims without some or all of these specific details. purpose of clarity, the technical material that is known in the technical fields related to the invention has not been described in detail, so that the invention is not necessarily unknown.
Routing multiple point-to-point data without an overlay - or mallaring of dedicated track tunnels - provides the desired scaling, signaling and provisioning properties. A value or header label referred to herein as a source station identification (SSID) is added to a package encapsulated header, such as through the addition of the SSID as a label at the bottom of a stack of MPLS tags, or as a redacted control that is added between the MPLS header and the VPN data. The SSID comprises a unique identifier that recognizes the PE that originated the packet. In some modalities, the Internet Protocol (IP) address of the originating PE could be used as the SSID for this PE. The IP address could be included as a control word between the MPLS header and the VPN data. The PE receiving this packet can then associate the Ethernet MAC address of the received TLS traffic source, for example, with the originating PE. Given the IP address of the originating EP, it is able to determine which LSP to use to send the Ethernet traffic (the Ethernet is a local area network system) to the station with the learned MAC address. With the use of the techniques below, multiple point-to-point LSPs can be used more effectively for TLS, VPLS, HVPLS (the virtual private LAN hierarchical services), and other services. This allows the scale of LSPs to happen as an "n" order instead of "n2", as a conventional implementation as described above. With signaling, protocols, such as RSVP and BGP, can be used to distribute labels in a simple and simplified provisioning that happens because a single destination label is assigned by PE for each service. Figure 1A illustrates a system for learning a MAC address. The system 100 represents a series of data channels that extend through the service provider's network 101. Within the service provider's network 101 are the core or host routers 102-108. Although they are shown with four core routers, in other columns or trunk axes, a smaller or larger number of core routers could be used. A series of PEs 110-120 are located in the connections of the service provider 101 network. The PEs 110-120 provide the entry / exit of the entry / egress points of the network of the service provider 101 for the client connection devices (CE) 122-138. The CEs 122, 124, 128 and 138 are associated with a particular client and / or service and provide additional routing to the destinations associated with the client and / or service. As used in this document, the term "router" refers to any equipment used to direct or route data from a source to a destination, and could include any node within a customer or provider network that performs this routing function. . At this point, the Al, A2, B, C and D destinations are examples of destinations that route traffic data through the CEs 122, 124, 128 and 138. The system is configured in this example, similar to a " inverted tree "or multiple-point-to-point configuration where source stations Al, A2, C and D are in data communication with destination station B, with traffic from stations Al, A2, C and D intended for the station B that is being transported through a multiple point-to-point LSP 139, shown in Figure 1A as a series of arrows in dotted lines originating in PE 110 and PE 114 and terminating in PE 120, through which PEs 110 and 114 are configured to send traffic to PE 120. Similarly, traffic for stations associated with PE 110, for example, Al, A2 and C would be sent from the stations B or D through a second LSP of multiple points-to-point (not shown in the Figure 1A) having PE 114 and PE 120 as entry points and PE 110 as the destination EP, and traffic for the stations associated with PE 114, for example, D, would be sent from stations Al, A2, B or C through a third LSP MP2P (not shown in Figure 1A) having PE 110 and PE 120 as entry points and PE 114 as the destination PE. In this way, the locations and network stations associated with the CEs 122, 124, 128 and 138 could be linked in a virtual network, such as the virtual private LAN service, using a mesh of MP2P LSPs, whereby the Client network traffic, for example, Ethernet traffic is transported between locations transparently to users of different client stations. Although only the CEs 122, 124, 128 and 138 are shown in data communication with the client networks, in other modalities, the number of CE routers could be different, depending on the backbone or network service provider (NSP) ), the number of clients, the number of nodes and other network influence factors. As noted previously, a problem that must be addressed when using MP2P LSPs as described in this document is the need for a destination PE (ie, the LSP MP2P endpoint) that will be able to "learn" the source MAC address of the original sender of a packet received by the PE through LSP MP2P and can associate this MAC address with the incoming PE through which it entered and was sent through LSP MP2P. In one embodiment, a source station identification (SSID) can be attached to the header of a packet or data link box in the ingress PE, such as by adding SSID as an additional tag at the bottom of a MPLS label stacking. Based on the reception by an egress EP, SSID is used to associate the MAC address for the source station that originated the packet (for example, the MAC address for CE 122 for a packet sent by the Al station, with the PE The number of tags distributed by PE of one-by-VPN-by-the-same-PE can be reduced to distribute a tag based on one-by-one. -VPN.If SSID were not the IP address of the PE router, then a separate configuration to map SSID to the PE router could be used.The MP2P LSP shown in Figure 1A could be used, for example, to transport a network packet of customer sent from station Al to station B. This package originated by station Al would be - provided to the entrance PE 110 through CE 122 .. The package would be encapsulated by PE 110 for transport through LSP MP2P to PE 120, the encapsulated or includes a header comprising a VC tag associated with LSP, and then it would be routed or routed between core or core routers 102, 104 and 108, before reaching the connection of the service provider's network 101 in the PE 120 of exit Then, PE 120 would de-encapsulate the packet, reconfigure it as appropriate for the client network, and send it to CE 138, from which it would be delivered to destination station B. The path used is an LSP tunnel that can be established through the signaling of the road in the different routers along its length. Several types of signaling protocols could be used and are not limited to those described in this document (eg, BGP, RSVP, etc.). In addition, other protocols than MPLS could be used to establish the tunnel architecture as described. The largest detail is provided with respect to the routing of data traffic which in turn is provided below in connection with Figure IB. Figure IB illustrates a system for learning a MAC address, showing a table 140 used to map SSIDs with an associated identifier LSP (ID LSP) and FIB 142 is used for the associated MAC source addresses with a corresponding LSP ID for a Private VPN. In an MP2P LSP, an LSP ID could be used to identify a "circuit" or dedicated path from two or more entry PEs located along the connection of the service provider's network 101 with a destination PE. In the example shown in Figures 1A and IB, an LSP ID could be used to identify the MPP MPP that connects the ingress PSs 110 and 114 with the destination PE 120. Similar LSPs, recognized by the associated LSP IDs, could be established to transport traffic to other PEs participating in a particular service, such as LSP that allows PE 110 and PE 120 to send traffic to PE 114 and an LSP used by PE 114 and PE 120 to send traffic to PE 110. According to a common procedure, each of the destination PE signals towards the other PEs participating in a service, such as a transparent LAN service, a VC tag will be used to send the traffic associated with the service to this PE. For example, PE 110 could signal to PE 114 and PE 120 that the VC label "101" should be used to send the traffic associated with the service to PE 110, and PE 114 could signal to PE 110 and PE 120 that the VC label "302" must be used to send the traffic associated with the service to PE 114. The numbers used in the example are completely arbitrary, and any suitable number could be assigned according to the applicable protocols used to establish and provide LSP. In order to know how to route the return traffic, each PE must "learn" an association between the source MAC address in the received packets and an LSP ID associated with the incoming PE device that sent the received packet through LSP MP2P, that is, each PE must fill an FIB such as FIB 142 of Figure IB. In the case of PE 120, for example, initially PE 120 fills table 140 by associating the LSP ID signaled with this for use by each PE participating in the service with SSID for this PE. In the example shown in Figure IB, table 140 has been filled with an entry that associates the LSP ID "101" with SSID for PE 110. In table 140, the SSID is listed as "PE 110" for convenience and clarity , although as noted previously, the IP address of the PE could be used as SSID. When a packet originating from station Al and addressed to station B is received by PE 120, if there were no entry in FIB 142 for the associated source MAC address, an entry would be created upon entering the source MAC address and associating it with the IS LSP incorporated with the entry PE from which the package was received. The PE 120 guarantees that a received packet is sent to the correct CE. However, in other embodiments, a control word, identifier or label could be used to identify an EC and thus allow PE to send the packet without requiring the search for an additional MAC address. As shown in Figure IB, this could be achieved by reading the SSID (included as an additional label in the stack, for example, as described above), using table 140 to map the SSID with a corresponding LSP ID, and subsequently, associating this LSP ID with the source MAC address in FIB 142. If in the future a PE 120 were required to handle the output traffic destined for the MAC address associated with the Al station, PE 120 would refer to FIB 142 to obtain the LSP ID that will be used to transport the package to the correct PE (in this case, PE 110). Figure 2 illustrates a header of the example package that includes a source identifier for learning a MAC address. Several fields are included in the header of packet 200, which represents the encapsulated data that is used to route a packet or link box between a source and a destination station. The label VC 202 indicates the virtual tunnel of the circuit path that is intended to follow the particular data packet. Track specific tunnels are provided between particular endpoints, which are assigned based on a specific QoS. The EXP 204 bits are part of an MPLS header, which provide an experimental value. If the encapsulated link box was an Ethernet link box having an IEEE 802. VLAN tag, the p-bits of the tag could be mapped to the bits EXP at the endpoint of the ingress tunnel. The EXP bits could be mapped back to the p-bits of a VLAN tag at the end point of the egress tunnel. Bit S 206 denotes the lower part of the label stack. The TTL value 208 provides a time-of-life value of the VC tag. The label VC 202, the bits EXP 204 and the value TTL 208 are in this mode standard components of the MPLS header. A reserved field 210 is provided for the additional header information. The notices 212 provide a field for other labels and identifiers that can be used to recognize the resources or portions of a particular path along which the data can be routed. The length 214 could be used to define the length of certain specific fields within the encapsulated header packet. Sequence number 216 determines the order for the packet or data link box in order to guide reassembly based on arrival at a destination station. Reserved field 210, warnings 212, length 214, and sequence number 216 are collectively identified as control words for use with MPLS implementations. Finally, an additional control word is contained in SSID 218. SSID 218 is included, providing a control word that can be associated with a source source station (eg, originating PE) for the purpose of allowing the end point of the egress tunnel "learn" the origins of the MAC address and associate them with the transport tunnels for the outbound traffic associated with this learned MAC address. Preferably, an SSID is a 4-byte field that provides an identifier associated with a source station. However, in other modalities the field length could be longer or smaller. Through the learning of the particular source address, connection routers such as PEs 110-120 are able to determine where a particular packet is originated and where the response packets should be addressed. Figure 3 illustrates a process for associating a source station identifier with a source MAC address. An identifier is added in a packet and is transmitted along a track tunnel, such as an LSP or VC (302). The identifier could be added through an entry point of LSP or VC, such as through a PE entry device. The identifier could be any value or sequence that is unique to the entry PE, such as the IP address of the PE. Once transmitted, the packet is received on a destination connection router (eg, PE) (304), which associates the identifier with a source station address (eg, the MAC address) (306). ). By associating a MAC address with the identifier, the connection router learns how to direct or route the data traffic back to a point of origin associated with the MAC address, without having to establish a current circuit or path or virtual point-to-point for each possible extreme point of origin, as described above. After the association of the MAC address with the identifier, the identifier is recorded in FIB in the particular connection router (for example, PE, CE) (308) Other PEs in the service provider's network 101 (Figures 1A, IB) that receive the packet, for example, in the case of a packet transmitted to all other PEs associated with a service, could similarly "learn" the association of the source MAC address with the identifier ( for example, SSID). In other modalities, other databases, management information bases (MIBs), or other repositories associated with provider connection routers (or devices) could be used to store the identifier (s). In conventional implementations, the inability of MPLS implementations to identify a source station for a packet received in an ingress router is resolved. In addition, the signaling protocols are also affected because a smaller number of track tunnels need to be signaled for establishment and reservation when an SSID is used. The use of SSID also allows services such as a transparent bridge, switch, or other TLS to be implemented more efficiently by providing a learning mechanism for the MAC address of the source station. Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative modes of implementation of the invention. The described modalities are illustrative and not restrictive. It is noted that in relation to this date the best method known by the applicant to carry out the aforementioned invention, is that which is clear from the present description of the invention.

Claims (23)

  1. CLAIMS Having described the invention as above, the content of the following claims is claimed as property: 1. A method of data routing between a source station and a destination station using a protocol according to which the identity of the originating station could not be apparent to the destination station, the data includes an associated source address with a node that originally sent the data, characterized in that it comprises: receiving the data at the destination station; extracting from a header associated with the data a source station identifier associated with the originating station and included in the header through the originating station; and associate the identifier of the source station with the source address.
  2. 2. The data routing method according to claim 1, characterized in that, according to the protocol, the data is sent from the originating station to the destination station through a multi-point label switched path to a point. .
  3. 3 . The data routing method according to claim 1, characterized in that the protocol comprises the protocol switching protocol of multiple protocols. Four . The data routing method according to claim 1, characterized in that the identifier of the source station is associated with a path in the originating station. 5 . The data routing method according to claim 1, characterized in that the source address comprises a MAC address associated with the node that originally sent the data. 6 The data routing method according to claim 1, further characterized by including the sending of a response packet to the node that originally sent the data through the originating station along a path associated with the identifier of the fountain station. The data routing method according to claim 6, characterized in that the route comprises a tagged pathway to the originating station. 8 The data routing method according to claim 1, characterized in that the association of the identifier "of the source station with the source address comprises the association with the source address of a track identifier associated with a track in the origin station. 9. The method of data routing between a source station and a destination station according to claim 1, further characterized in that it comprises sending the data from the destination station to a intended receiving node that is indicated in the data. 10. The method of data routing between a source station and a destination station according to claim 1, characterized in that the association of the source station identifier with the source address comprises the identification of a tunnel end point Of income. The data routing method according to claim 1, characterized in that the destination station comprises a connection router associated with a network of the service provider. The data routing method according to claim 1, characterized in that the association of the identifier of the source station with the source address includes the storage of the data associated with the identifier of the source station on a database basis. transmission information. 13. A method of routing data between a source station and a destination station using a protocol according to which the identity of the originating station could not be apparent to the destination station, the data includes an address source associated with a node that originally sent the data, characterized in that it comprises: adding a source station identifier associated with the source station to a header associated with the data; and send the -package from the station of origin to the destination station. The data routing method according to claim 13, characterized in that the format and the required content of the header is prescribed through the protocol and the addition of a source station identifier associated with the originating station in the header it comprises adding the identifier of the source station in a way that does not interfere with the normal processing of the header according to the protocol. The data routing method according to claim 13, characterized in that the protocol comprises the protocol switching protocol of multiple protocols (MPLS) and the addition of a source station identifier associated with the source station in the header includes the insertion of the source station identifier as an additional label at the bottom of the MPLS label stack. The data routing method according to claim 13, characterized in that the identifier of the source station comprises the IP address of the originating station. 17. A data routing system between a source station and a destination station using a protocol according to which the identity of the originating station could not be apparent to the destination station, the data includes a source address associated with a node that originally sent the data, characterized in that it comprises: a processor configured to extract from a header associated with the data, a source station identifier associated with the originating station and included in the header through the source and associates the identifier of the source station with the source address; and a memory configured to store the identifier of the source station and the source address. 18. The data routing system according to claim 17, characterized in that the data comprises an Ethernet link frame. 19. The data routing system according to claim 17, characterized in that the packet header is based on the switching of multiple label protocols. 20. The data routing system according to claim 17, characterized in that the processor is associated with the destination station. The data routing system according to claim 17, characterized in that the processor is associated with the destination station and the destination station comprises a provider connection router. 22. The data routing system according to claim 17, characterized in that the identifier of the source station is associated with a path that could be used to send data from the destination station to the originating station. 23. A computer program product of data routing between a source station and a destination station using a protocol according to which the identity of the originating station could not be apparent to the destination station, the data they include a source address associated with a node that originally sent the data, characterized in that it is included in a medium capable of being read by computer and comprises computer instructions for: receiving the data at the destination station; extracting from a header associated with the data an identifier of the source station associated with the originating station and included in the header through the originating station; and associate the identifier of the source station with the source address.
MXPA/A/2005/011579A 2003-04-28 2005-10-27 Source identifier for mac address learning MXPA05011579A (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US60/466,245 2003-04-28
US10742226 2003-12-18

Publications (1)

Publication Number Publication Date
MXPA05011579A true MXPA05011579A (en) 2006-10-17

Family

ID=

Similar Documents

Publication Publication Date Title
EP1618688B1 (en) Source identifier for mac address learning
CN111713079B (en) Packet network interworking including segment routing
JP3947471B2 (en) Network tunneling
US7756125B2 (en) Method and arrangement for routing pseudo-wire encapsulated packets
US7283529B2 (en) Method and system for supporting a dedicated label switched path for a virtual private network over a label switched communication network
US7733883B2 (en) Method for implementing a virtual leased line
US9166807B2 (en) Transmission of layer two (L2) multicast traffic over multi-protocol label switching networks
US7430210B2 (en) Application of an Ethernet/MPLS “half bridge” to provide emulated Ethernet LAN functions in SONET networks
EP2135394B1 (en) MPLS transport network scheme
US20050169270A1 (en) Router, frame forwarding method, and lower layer frame virtual forwarding system
US6944159B1 (en) Method and apparatus for providing virtual point to point connections in a network
US20020110087A1 (en) Efficient setup of label-switched connections
JP2005341591A (en) Virtual private network, and multi-service provisioning platform and method
US7499449B2 (en) Virtual Ethernet MAC switching
US7161946B1 (en) Technique for multiprotocol transport using MPLS (multi-protocol label switching)
US20120224579A1 (en) Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) Over Routed Ethernet Backbone
JP3910200B2 (en) Router, frame forwarding method, and lower layer frame virtual forwarding system
US7797444B2 (en) Data transfer apparatus and data transfer system
MXPA05011579A (en) Source identifier for mac address learning
KR100684143B1 (en) Method and apparatus for providing various L2VPN service using Simplified multi protocol Label Switching mechanism
EP1978683A1 (en) Method and device for data transport and system comprising such device
Li Design, implementation and performance evaluation of MPLS layer 2 Martini VPN