WO2005006670A1 - ラベルスイッチネットワークにおけるセッション確立方法及びラベルスイッチノード - Google Patents

ラベルスイッチネットワークにおけるセッション確立方法及びラベルスイッチノード Download PDF

Info

Publication number
WO2005006670A1
WO2005006670A1 PCT/JP2003/008710 JP0308710W WO2005006670A1 WO 2005006670 A1 WO2005006670 A1 WO 2005006670A1 JP 0308710 W JP0308710 W JP 0308710W WO 2005006670 A1 WO2005006670 A1 WO 2005006670A1
Authority
WO
WIPO (PCT)
Prior art keywords
label
session
message
label switch
adjacent
Prior art date
Application number
PCT/JP2003/008710
Other languages
English (en)
French (fr)
Inventor
Yasushi Sasagawa
Original Assignee
Fujitsu Limited
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 Fujitsu Limited filed Critical Fujitsu Limited
Priority to PCT/JP2003/008710 priority Critical patent/WO2005006670A1/ja
Priority to JP2005503838A priority patent/JP4109692B2/ja
Publication of WO2005006670A1 publication Critical patent/WO2005006670A1/ja
Priority to US11/262,188 priority patent/US20060062218A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • H04L45/507—Label distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding

Definitions

  • the present invention relates to a session establishment method and a label switch node in a label switch network, and more particularly to a technique suitable for use in a network or a node adopting MPLS (Multi Protocol Label Switching) or a protocol extended from MPLS.
  • MPLS Multi Protocol Label Switching
  • Patent Document 1 area-limited high-speed communication system and service realization method.
  • the technology of Patent Document 1 is a region-limited high-speed communication system using a well-known high-speed LAN technology such as a gigabit LAN (Local Area Network), and includes region ID information for specifying a region limited to a communication frame and a user ID.
  • a communication frame that includes industry ID information that identifies the type of business and user ID information that identifies the user, users within a limited area for users who use high-quality video It performs high-speed data communication.
  • MPLS uses “labeling” instead of IP header routing for IP packets.
  • This is a technology that uses short fixed-length path identification information called “Nore”.
  • Routers that support MPLS generally called LSRs (Label Switching Routers)
  • LSRs Label Switching Routers
  • LDP label distribution protocol
  • G Generalized MPLS (also called MP (l) S, which uses TDM (Time Division Multiplexing) time slots and optical wavelengths (1) of photonic networks for ⁇ labels '' (Packet repeaters, TDM repeaters, optical wavelength repeaters, etc.), and networks and applications configured using them
  • MPLS L2 Layer 2
  • MPLS L3 Layer 3
  • MPLS-TE Traffic Engineering
  • GMPLS etc.
  • the LDP identifier is Consists of an LSRO Label Switching Router) identifier (LSR ID) (4 octets) and a label space identifier (Label space ID) (2 octets), for a total of 6 octets. It identifies the label space transmitted by the LSR.
  • LSR ID LSRO Label Switching Router
  • Label space ID label space identifier
  • LSR identifier is a global value that identifies the LSR, and it is generally recommended to use a router ID.
  • Label space identifier is a value that identifies the label space used in the LSR.
  • the former “basic discovery mechanism” is used to automatically detect directly (physical) connected neighbor LSRs and establish a “Hello” neighbor
  • a Hello message with a destination IP address of a multi-cast address (224.0.0.2) is transmitted as a UDP (User Datagram Protocol) packet to automatically detect Hello neighbors. Detected (detected by receiving Hello Message from adjacent LSR). Therefore, in the “Basic device force validation mechanism”, provisioning (pre-setting) for establishing a halo neighbor is unnecessary.
  • the IP address of the own interface is used as the source IP address of the hello message, but the specifics to be used are implementation items (for example, the interface address, loopback address, and LDP session dedicated address). Etc. can be used).
  • the extended discovery mechanism detects hello neighbors that are not directly connected by transmitting a hello message with the destination IP address as a specific unicast IP address in a UDP bucket, and detects hello neighbors. Is established. Therefore, the “extended discovery mechanism” requires provision for establishing a hello neighbor. Also in this case, the IP address of the own device (implementation items are used to determine what to use) is used as the source IP address.
  • a Hello message is transmitted / received between adjacent LSR # 1 and LSR # 2 (Step A1), and a Hello adjacency is established (Step A2).
  • a TCP Transmission Control Protocol
  • a transport connection TCP
  • an initialization message is transmitted.
  • an LDP session is established by periodically transmitting and receiving a Keep Alive Message (Steps A7 to A12). (Stay A1 3).
  • the address of the LDP peer used for the forwarding decision of the MPLS bucket (labeled packet) is exchanged between LSR # 1 and LSR # 2 using an Address Message.
  • label mapping message Label Mapping Message
  • label mapping label mapping
  • the “Martini” method which is one of the MPLS L2 VPNs (Virtual Private Networks) (a method for providing a virtual leased line (PW: pseudo wire) on L2 (Layer 2) using MPLS) is newly introduced.
  • Forvvarding Equivalence Class (FEC) j type rpw FEC element] and its corresponding PW [formerly VC (Virtual Channel)] TLV (TVpe / Length Value) are additionally defined.
  • FEC Forvvarding Equivalence Class
  • use Specifically, use the rdownstream unsolicited mode and the extended discovery mechanism.
  • PE # 1, PE # 2, and PE # 3 represent LSRs called Provider Edges that connect to other networks, respectively, and Core LSRs represent other LSRs.
  • PE # 1 is physically connected to the core LSR
  • PE # 2 is physically connected to the core LSR and PE # 3
  • PE # 3 is physically connected to the core LSR and PE # 2 (indicated by solid lines).
  • control messages such as OSPF (Open Shortest Path First) and LDP can be transmitted and received by all LSR CPEs and core LSRs. is there.
  • OSPF Open Shortest Path First
  • control messages include (1) TCP / IP as is [no encapsulation: In case of OSPF (Open Shortest Path Fast) -IP, LDP-TCP], (2) Label (passes through the LSP previously set) In the case of a pusher, (3) Other cases such as LL2TP (Layer 2 tunneling protocol) and GRE (Generic Routing Encapsulation) are possible.
  • a normal LDP session is established between all adjacent LSRs (PE, core LSR) as described in the above “Basic Discovery Mechanism J”. Is established using
  • All PEs (PE # 1-PE # 2, PE # 1-PE # 3, PE # 2-PE # 3) as shown by the dotted arrows 50,000, 600, and 700 in Fig. 18. Establish an LDP session using an "enhanced discovery mechanism" with full mesh in between. At this time, all the IP addresses of the LSRs at the connection destination (remote side) must be provisioned to each of PE # 1, PE # 2, and PE # 3.
  • LDP session 400 has already been established according to the above (1) Establishing the communication path for control messages.
  • the LDP session 700 needs no new setting. Also, it cannot be set strictly according to the provisions of RFC3036. If you do not know that PE # 2 and PE # 3 are next to each other, try to set up this session. To address this, the following implementations of 1 to 3 can be considered. (1) Provisioning clearly indicates that they are adjacent to each other, and does not set the session 700.
  • the set of LSPs 500A and 500B is a normal LDP session 500 between PE # 1 and PE # 2
  • the set of LSP60OA and 600B is the PE.
  • a set of a normal LDP session 600 between # 1 and PE # 3 and a set of LSPs 700A and 700B indicate a normal LDP session 700 between PE # 2 and PE # 3, respectively.
  • LSPs 500B and 600B from PE # 2 and PE # 3 to PE # 1 are merged by the core LSR.
  • the LSP for PW is established by distributing the label in the “Label Mapping” message with the FEC for PW described above on the LDP sessions 500, 600, and 700 established between the PEs.
  • PW is a pair of FW LSPs in the opposite direction between the same PE (shown in Fig. 21; PWLSP500a and 500b or PW LSP600a and 600b or PW LSP700a and 700b)
  • the PWID in the FEC for PW must be provisioned in both PEs in advance.
  • the LSP 700 for PW between PE # 2-PE # 3 is required.
  • a, 700 b may be passed through the tunnel LSP 70 OA, 700 B as shown, or may be set independently of the tunnel LSP 700 A, 700 B. However, in the tunnel LSP 700 A, 700 B If you use PHP, the tunnel label will not be added.
  • the “Martini” method does not specify: LSP tunneling for PW. Therefore, management Z operation (for example, separation of control message and user data to facilitate management) or service [for example, QoS for user data
  • LSP LSP for F using LDP session between PEs.
  • the direct routes between PE # 1 and PE # 2 and between PE # 1 and PE # 3 are the normal LSP 500 A, 500 B, 60 OA, 600 B (500 B and 600 B
  • these LSPs 500A, 500B, 600A, and 600B will be used as tunnel LSPs.
  • ⁇ Routes can be set independently of IP routes.
  • An LSP equivalent to the normal LSP described above is set by CR-LDP / RSVP-TE. In this case, it has the following features.
  • Routes can be set independently of IP routes.
  • Control message path There are various variations in Z encapsulation (in some cases, some form of vision is required).
  • the PW ID is provisioned by both concerned PEs and notified by a label mapping message. Therefore, this provisioning error is not known (cannot be detected) until a label matching message is sent or received.
  • LDP Label distribution protocol
  • the ability of the LDP entities at both ends of the session to implement the rMartiniJ-style extension or, if implemented, to be provisioned to use it depends on the label mapping phase. I don't know. Also, even if both parties implement and use the "Martini” method, various provisioning information in the "Martini” method MPLS L2 VPN shown in (1) to (5) above If it is incorrect, it cannot be detected on the protocol and malfunctions, or even if it can be detected, it cannot be reliably detected when establishing an LDP session. A specific example will be described below with reference to the network configuration shown in FIG.
  • PE # 1 is a device that cannot send and receive IP packets (control messages) as it is, and can only send and receive IP packets that have been converted into cells by MPLS. (If the rMartiniJ method is implemented in a bridge-based device, hardware Such implementation is conceivable from the viewpoint of restrictions and implementation costs). In addition, this equipment shall be capable of dynamically setting LSPs by LDP, except for the above LSPs.
  • PE # 2, PE # 3, and the core LSR can send and receive IP buckets as they are, and can also send and receive IP buckets encapsulated by MPLS.
  • control messages are transmitted and received in the LSP, and the LSP for the PW tunnel and the LSP for the control message are separated.
  • an LSP for control messages must be statically set between PE # 1 and the core LSR.
  • PE # 2 PE # 3, and core LSR, it is necessary to set an operation policy to send and receive control messages in the LSP.
  • explicit provisioning or setting the priority of the IP route and the LSP route can be considered.
  • PE # 1, PE # 2, and PE # 3 must not send control messages during the LSP set in (3) above.
  • the tunnel LSP for PW cannot be set, or: Even if the tunnel LSP for PW can be set, recognition is shifted at both ends.
  • MPLS applications extend or use LDP as is, are being standardized one after another, and are being developed independently.
  • some applications cannot use the same LDP session.
  • LDP's labeling mode is not compatible between S ⁇ Downstream Unsolicited J mode '' and ⁇ Downstream on Demandj, so if the aggregation uses different modes, use the same LDP session.
  • Non-patent document 1 L. Andersson et al "" LDP specification "(Request for Comments), [online], January 2003, Network Working Group Internet Draft of IETF [Search on June 16, 2003], Internet http: httpwww.iet £ org / rfc / rfc3036.txt>.
  • a method for establishing a session in a label switch network comprises a plurality of label switches having a function of routing a reception bucket in accordance with label information distributed by a predetermined label distribution port.
  • session identification information for identifying a session to be established between adjacent label switch nodes is added to a message transmitted / received between adjacent label switch nodes by the label distribution protocol. Transmitting and receiving the message, wherein the same adjacent label switch node establishes a plurality of sessions used in the same label space between the same adjacent label switch nodes based on the session identification information, respectively.
  • the method for establishing a session in a label switch network of the present invention is a label switch network comprising a plurality of label switch nodes having a function of routing a reception bucket according to label information distributed by a predetermined label distribution protocol.
  • session type information specifying one or both of an application using a session to be established between the adjacent label switch nodes and a use thereof is added.
  • the adjacent label switch nodes respectively transmit and receive the message based on the session type information, and perform the session according to the session type information between the adjacent label switch nodes. It is characterized by establishing a.
  • a method for establishing a session in a label switch network is a label switch network comprising a plurality of label switch nodes having a function of routing a reception bucket according to label information distributed by a predetermined label distribution protocol.
  • a message transmitted and received between adjacent label switch nodes according to the label distribution protocol includes session identification information for identifying a session to be established between the same adjacent label switch nodes, and any one of an application using the session and its use.
  • the message is transmitted / received by adding session type information indicating one or both, and the same adjacent label switch node is configured to transmit the message based on the session identification information and the session type information, respectively.
  • Rereru used in the same label space between of identity one adjacent label sweep rate Tutsi node, establishing a plurality of sessions corresponding to the set Chillon type information as a feature.
  • the session type information is added to the hello message as the message.
  • the session type information may be exchanged between the adjacent label switch nodes at the time of establishing a halo neighbor between the adjacent label switch nodes, or the session information may be added to the initialization message as the message.
  • the session type information may be exchanged between the adjacent label switch nodes when a session is established between the adjacent label switch nodes.
  • provisioning information on the entity of the label distribution protocol may be added to the message and exchanged.
  • the label switch node of the present invention has a function of notifying a received packet according to label information distributed by a predetermined label distribution protocol, and the adjacent label switch is performed by the label distribution protocol.
  • a label distribution protocol processing unit for transmitting / receiving the message by adding session identification information for identifying a session to be established between the same adjacent label switch nodes to a message to be transmitted / received to / from the node; Based on the session identification information added to the message of the label distribution protocol received from the adjacent label switch node by the distribution protocol processing unit, establishes a plurality of sessions used in the same label space with the adjacent label switch node.
  • a session establishment control unit that controls It is characterized in.
  • the label switch node of the present invention has a function of routing a received packet according to label information distributed by a predetermined label distribution protocol, and transmits / receives to / from an adjacent label switch node by the label distribution protocol.
  • the message to be attached is attached with session type information that specifies one or both of an application using a session to be established with the adjacent label switch node and its use, and sends and receives the message.
  • the label distribution protocol processing unit based on the session type information added to the label distribution protocol message received from the adjacent label switch node by the label distribution protocol processing unit. Between the adjacent label switch node and the session type information And a session establishment control unit for controlling the establishment of the corresponding session. It is characterized by that.
  • the label switch node of the present invention has a function of routing a reception bucket in accordance with label information distributed by a predetermined label distribution protocol, and has a function of communicating with an adjacent label switch node by the label distribution protocol.
  • the session identification information for identifying the session to be established with the adjacent label switch node, the application that uses the session and the application, its use, and / or
  • a label distribution protocol processing unit for transmitting and receiving the message by adding session type information indicating both, and a message of the label distribution protocol received from the adjacent label switch node by the label distribution protocol processing unit.
  • Session identification information and session type information A session establishment control unit for controlling the establishment of a plurality of sessions according to the session type information used in the same label space between the adjacent label switch node and the adjacent label switch node. It is characterized by.
  • the label distribution protocol processing unit adds the session type information to a hello message as the message of the label distribution protocol, thereby establishing a halo neighbor with the adjacent label switch node.
  • a hello message processing unit for exchanging the session type information with the adjacent label switch node may be provided.
  • the label distribution protocol processing unit adds a session type information to an initialization message as the message of the label distribution protocol, thereby performing a session with the adjacent label switch node.
  • An initialization message processing unit for exchanging the session type information with the adjacent label switch node at the time of establishment may be provided.
  • the label distribution protocol processing unit may include a provisioning information exchange processing unit for adding provisioning information relating to the entity of the label distribution protocol to the message and exchanging the message.
  • the label distribution protocol processing unit sets a tunnel label switch path in advance with the adjacent label switch node when the session establishment control unit establishes the session with the adjacent label switch node.
  • Doing tunnel la The provisioning information exchange processing unit may include a bell switch path setting unit. In this case, the provisioning information exchange processing unit includes the provisioning information added through the tunnel label switch path set by the tunnel label switch path setting unit. It may be configured to exchange messages.
  • provisioning information exchange processing unit adds a TLV for transferring the provisioning information to one or both of an initialization message and an address message transmitted and received between the adjacent label switch nodes according to the label distribution protocol. May be configured.
  • provisioning information exchange processing unit may be configured to generate a message for transferring the provisioning information newly defined in the label distribution protocol, or may be configured to generate a message newly defined in the label distribution protocol. It may be configured to generate a message for revoking provisioning information.
  • FIG. 1 is a diagram showing a configuration of an MPLS network (label switch network) as one embodiment of the present invention.
  • FIG. 2 is a functional block diagram showing the configuration of the LSR of the present embodiment.
  • FIG. 3 is a diagram for explaining an example of extending the LDP PDU of the present embodiment.
  • FIG. 4 is a format diagram for explaining a new definition example of the session type (Session TYPE) TLV of the present embodiment.
  • FIG. 5 is a format diagram for explaining an example of a new definition of an application type (Application TYPE) TLV of the present embodiment.
  • FIG. 6 is a format diagram for explaining an example of a new definition of a session name (Session Name) TLV of the present embodiment.
  • FIG. 7 is a format diagram for explaining an extended example of the Hello message of the present embodiment.
  • FIG. 8 is a format diagram for explaining a common hello parameter (Common Hello Parameters) TLV of the present embodiment.
  • FIG. 9 shows the initialization message (Initialization message) of this embodiment.
  • FIG. 9 is a format diagram for explaining an extended example 1 of the Message).
  • FIG. 10 is a format diagram for explaining the Common Session Parameters TLV of the present embodiment.
  • FIG. 11 is a format diagram for explaining an example of a new definition of the Provisioning Information TLV of the present embodiment.
  • FIG. 12 is a format diagram for explaining a PW parameter (Pseudo Wire parameter) TLV of the present embodiment.
  • FIG. 13 is a format diagram for explaining an example of newly adding a provisioning message according to the present embodiment.
  • FIG. 14 is a format diagram for explaining an extended example of an address message (Address Message) of the present embodiment.
  • FIG. 15 is a sequence diagram for explaining an LDP session establishment procedure in the MPLS network of the present embodiment.
  • FIG. 16 is a sequence diagram for explaining a procedure for establishing an LDP session in a conventional MPLS network.
  • FIGS. 17 to 21 are diagrams showing network configuration examples for explaining the establishment of the conventional rMartiniJ method LDP session and LSP, respectively.
  • FIG. 1 is a diagram showing the configuration of an MPLS network (label switch network) as an embodiment of the present invention.
  • the MPLS network 1 shown in FIG. 1 is an LSR 11 as a plurality of label switch nodes supporting the MPLS function. Are connected to each other in a mesh form.
  • the MPLS network 1 is connected to the external networks 2, 3, and 4 via ordinary routers (or bridges) 21, 31, and 41 that constitute the external networks 2, 3, and 4. I have.
  • the LSR 11 located at the connection with the external networks 2, 3, 4 [router (or bridge) 21, 31, 41] is especially LER (Label Edge Router) (PE in IP-VPN).
  • the other LSRs 11 are called core LSRs.
  • (1) multiple LDP sessions can be established between the same adjacent LSRs 11 and (2) applications and / or uses of LDP sessions can be clearly identified.
  • (3) automatic detection of provisioning information of LSR 11 is enabled, and it is possible to detect erroneous wiring (erroneous connection) due to an error in provisioning information and a setting error of Z or provisioning information. I have.
  • the LSR 11 focuses on the main parts thereof.
  • the MPLS L2 VPN application unit 111 and the traffic engineering application unit 112 CL / NMS interface section 113, provisioning information management section 114, MPLS processing section 115, IP routing processing section 116, topology information management section 117, label distribution signaling processing section 111 8, label management section 119, MAC filtering database processing section 120, label switching processing section 121, switch control section 122, line interface section 123, etc.
  • lines shown by solid lines represent interfaces between these functional blocks, and lines shown by dotted arrows represent data reference (access) paths between the functional blocks.
  • the MPLS L2 VPN application unit 111 sends a label to the MPLS processing unit 115 as necessary according to the provisioning information managed by the provisioning information management unit 114.
  • the MPLS L2 VPN application unit 111 sends a label to the MPLS processing unit 115 as necessary according to the provisioning information managed by the provisioning information management unit 114.
  • the following functions are extended.
  • session ID session identification information
  • This session ID may be automatically generated by the application unit 111 or may be provisioned (managed by the provisioning information management unit 114).
  • the traffic engineering application unit 112 establishes a label distribution signaling session with the MPLS processing unit 115 as necessary according to the provisioning information managed by the provisioning information management unit 114.
  • the load distribution LSP is established, Z release, and load distribution parameters are specified (multiple LSPs to be mapped, load distribution upper limit threshold, load distribution upper limit threshold, etc.).
  • the function has been extended so that a session ID can be added when instructing session establishment.
  • the session ID may be automatically generated by the application section 112 or may be provisioned.
  • the CL / NMS interface section 113 manages an interface with the CL (command line) and / or NMS (network management system), and here, in cooperation with the provisioning information management section 114. It has a function to set and display management information. Further, the provisioning information management unit 114 sets and displays the provisioning information according to the instruction from the CL / NMS interface unit 113 and makes the provisioning information referable to each function block. Things. For the remote-side provisioning information, the setting from the corresponding function block may be possible (it may be managed).
  • the MPLS processing unit 115 establishes / releases signaling sessions for label distribution according to instructions from various applications (here, the MPLS L2 VPN application unit 111 and traffic engineering application unit 112), and performs various LSPs.
  • applications here, the MPLS L2 VPN application unit 111 and traffic engineering application unit 112
  • LSPs various LSPs.
  • the label switching processing unit 121 It also has the function of instructing setting / changing / release of the label forwarding table.
  • the MPLS processing unit 115 controls establishment of a necessary LDP session in accordance with a label distribution signaling message (LDP message) received from an adjacent LSR via the label distribution signaling processing unit 118 described later. It functions as a session establishment control unit. However, in the present embodiment, the following function expansion is also performed.
  • LDP message label distribution signaling message
  • the session ID is added when the label distribution signaling session establishment instruction is given.
  • the IP routing processing unit 116 maintains the dynamic topology information of the network 1 by executing the IP routing protocol in cooperation with the topology information management unit 117.
  • the management unit 117 maintains and manages the dynamic topology information of the network in cooperation with the IP routing processing unit 116, and provides the topology information and its change to necessary function blocks. Is what you do.
  • Label distribution signaling processing unit (Label distribution protocol processing unit) 118 establishes / releases label distribution signaling session and establishes / releases various LSPs according to instructions from MPLS processing unit 115 At the same time, the MPLS processing unit 115 notifies the MPLS processing unit 115 of the Z release of the label distribution signaling from the remote device and the establishment of various LSPs and the release of the Z release, and requests the subsequent processing.
  • the LDP message can be extended to provide and exchange the session ID, information (session type information) specifying one or both of the application of the LDP session to be established and its use, and provisioning information. Various functions are extended (LDP extension: details will be described later).
  • the label management unit 119 provides the label distribution signaling processing unit 118 with the function of managing the empty / occupied state of the label allocated by the own device. Access Control)
  • the finalizing database processing unit 120 is linked with the provisioning information management unit 114 and the line interface processing unit 123 (#l to #m, where m is a natural number) to perform MAC filtering. It manages the original database, provides the necessary MAC filtering database to each line interface processing unit 123, and instructs the switch control unit 122 necessary switching. It is.
  • the label switching processing section 121 manages the original label forwarding table in accordance with the instruction from the MPLS processing section 115, and supplies the necessary label format to each line interface processing section 123. This is for providing a switching table and instructing the switch control unit 122 to perform necessary switching.
  • the switch control section 122 communicates with each line interface processing section 123 and the necessary functional blocks in its own device.
  • Each of the line interface processing units 123 accommodates one or more lines (# 1 to #n), and includes a MAC filtering database processing unit 120 and a label switching processing unit 1. According to the instructions from 21 above, frames are transmitted and received by referring to the MAC filtering database / label forwarding table (not shown).
  • LDP (RFC3036) is extended so that multiple LDP sessions can be established between the same adjacent LSRs 11.
  • RRC3036 LDP (RFC3036) is extended so that multiple LDP sessions can be established between the same adjacent LSRs 11.
  • the following methods ⁇ 1> and ⁇ 2> can be considered.
  • the LDP identifier is extended (changed) without changing the format of the LDP PDU, and multiple LDP sessions between the same adjacent LSR 11 can be identified by the session identification information (session ID).
  • the LDP identifier is defined in RFC3036 as "LSH ID” (a global value that identifies the LSR composed of 4 octets) and "Label space ID” (identifying the label space composed of 2 bits) "0" for "platform-wide” label space, "1" indicates the label space of "per interface”, "3" and "4" indicate the reserve), and "Session ID” consisting of 14 bits is newly defined.
  • LSH ID a global value that identifies the LSR composed of 4 octets
  • Label space ID identifying the label space composed of 2 bits
  • a session ID field 12 is newly defined in the format of the LDP PDU.
  • the "Session TYPE" TLVJ indicating the type or use of the session and / or the "Application TYPE” TLVJ indicating the type of the application using this session and / or this session
  • a new “Session name” TLVj is defined (referred to collectively as “session type information”) indicating the name of the TLV.
  • the TLV is labeled (labeled as “Hello message” or “Initialization message”).
  • Transmission / reception signaling unit 1 18) Sends and receives, and establishes a hello neighbor or LDP session only when they match. However, this does not apply to the “Session name TLV” if it is used only for maintenance and operation.
  • the label distribution signaling processing unit 118 of the present embodiment adds the “session type information” to the hello message as the LDP message, thereby establishing the hello adjacency with the adjacent LSR.
  • the common session parameters TLV Common Session Parameters TLV
  • the common session parameters TLV indicate the “session type” that indicates the type or use of the session and / or the type of the application that uses the session.
  • a new "Application TYPE" and / or "Session namej" parameter indicating the name of the session can be newly defined so that the above parameters can be sent and received, and a hello neighbor or LDP session can be established only when they match. However, this does not apply to “Session name TLV” if it is used only for maintenance and operation.
  • the label distribution signaling processing unit 118 adds the “session type information” to the initialization message as an LDP message, so that the label distribution signaling processing unit 118 can establish a hello adjacency with the adjacent LSR. It has a function as an initialization message processing unit for exchanging the information.
  • the above messages may be transmitted and received in the tunnel LSP, or may be transmitted and received via the IP route.
  • the following shows examples of adding and changing the above messages, TLVs, and parameters.
  • Fig. 4 shows an example of a new definition of the session type TLVJ.
  • the "session type TLV” has a "TLV type” field 21 indicating the type of the TLV, and a "Length (Length)”.
  • Finale 22 and “Session TYPE” J field 23 are prepared, and “TLV type” field 21 contains information indicating the type of TLV (in this case, “session type TYPE”).
  • “Length J field 22” information indicating the length of the TLV is set
  • the "Session TYPE J field 23 information indicating the type of session to be set is set.
  • LDP session (ldp session for control message) (others are reserved).
  • Session TYPEJ can set multiple supported types as shown in Fig. 4.
  • FIG. 5 shows an example of new definition of “Application Type TLV”.
  • “Application TLV” has “TLV type” field 31, “Length J field 32” and “Application type” field 33, and “TLV type” field 31 Indicates the type of TLV (in this case, “absorption”), “Length” field 32 indicates the length of the TLV, and “Application type” field 33 indicates And information indicating the type of session to be set.
  • FIG. 6 shows an example of a new definition of “session name TLV”.
  • “session name TLVJ has TLV type field 41,“ Length ”field 4 2 And “Session Name J field 43”
  • “Session Name TLVJ field 41 contains information indicating the type of TLV (in this case,“ TLV type ”indicating“ Session NameJ ”)
  • “ Length ( Length) ”field 42 sets information (character string) indicating the session to be set.
  • Figs. 7 and 8 show examples of the extension of "Hello Message J.”
  • "Hello Message” contains a message type [Hello Message in this case. (0x0100))
  • Message type field 51 indicating the message length
  • message length field indicating the length of the message
  • message ID field 53 indicating the length of the message
  • common Hello parameters Common Hello Parameters
  • a TLV field 54 and an optional parameter field 55 are provided.
  • the common hello parameter TLV field 54 includes a field 541 indicating a parameter type (common hello parameter) and the common hello parameter.
  • Parameter Length field 542 that sets the length (field length) of the TLV field 54 and Hold Time field 5443 are provided.
  • the optional parameter field 55 is set.
  • the information to be specified is expanded to include the existing parameters ("IPv4 Transport Address (0x0401)", “Configuration (0x0402)", “IPv6 Transport Address (0x0403) J)" and "Session TYPE” ( Each information of "Session TYPE TLV”, “Application TYPE” (Application TYPE TLV) and “Session Name” (Session Name TLV) can be set.
  • Fig. 9 shows Extended Example 1 of "Initialization Message”.
  • "Initialization” includes a message type field 61 indicating a message type [in this case, "Initialization (0x0200)"] and a message indicating the length of the message (Message Length).
  • a long field 62, a message ID file K63, a common session parameters TLV field 64 and an optional parameter field 65 are provided.
  • the common session parameter TLV field 64 further includes a field 641 indicating a parameter type (common session parameter), a length of the common session parameter TLV field 64 ( Length field for setting the field length, the protocol length field, the keep-alive time field, and the receiver LDP identifier field. Is prepared.
  • the common session parameter TLV field 64 includes a “Session TYPE” field 64 6 and an “Application TYPE”.
  • Field 647 and “Session Name” field 648 are additionally defined so that the information of “Session type”, “Application type” and “Session name” can be set.
  • an initialization message is used to explicitly specify the application and / or use of the LDP session to be established, its optional parameters may be extended. That is, in addition to the existing parameters (“ATM Session Parameters (0x0501) J, Frame Relay Session (0x0502) J, etc.)” as the optional parameters, ⁇ ⁇ Session TYPEj (Session TYPE TLV), “Application TYPEj (Application TYPEj (Application TYPEj) TLV), "Each information of Session NameJ (Session Name TLV) can be set.
  • the application and / or use of the LDP session to be established can be explicitly specified when the LDP session is established.
  • the information on the remote side is automatically obtained (or deleted (withdrawn)) by transmitting and receiving the provisioning information in an LDP message, and the incorrect wiring and Z or provisioning are performed. It can detect information setting mistakes.
  • the provisioning information may be added as a new TLV to an existing message (for example, an initialization message), or the message itself may be newly defined.
  • FIG. 11 shows an example of a new definition of “Provisioning information TLV”.
  • the “provisioning information TLV” contains a TLV type field 71 indicating the TLV type (in this case, “provisioning information”), and a TLV indicating the length of the “provisioning information TLV”.
  • a Length field 72 and a Provisioning Parameter field 73 are provided, and multiple rpw parameter (Pseudo Wire Parameter) TLVJs with the format shown in Fig. 12 are set as provisioning parameters. You can do it.
  • Fig. 11 shows an example of a new definition of “Provisioning information TLV”.
  • the “provisioning information TLV” contains a TLV type field 71 indicating the TLV type (in this case, “provisioning information”), and a TLV indicating the length of the “provisioning information TLV”.
  • a Length field 72 and a Provisioning Parameter field 73 are provided, and multiple rpw parameter (Pse
  • the ⁇ ⁇ ⁇ parameter TLVJ further includes a TLV type field 731 indicating the TLV type (in this case, “PW parameter”) and a TLV length field 7 indicating the TLV length.
  • TLV type field 731 indicating the TLV type (in this case, “PW parameter”)
  • TLV length field 7 indicating the TLV length.
  • the label distribution shidanering processing unit 118 of the present embodiment also functions as a provisioning information exchange processing unit that adds provisioning information on the LDP entity to the LDP message and exchanges it with an adjacent LSR. Will be.
  • the optional parameters can be extended to the existing parameters ("ATM Session Parameters (0x0501)", “Frame Relay Session”). (0x0502) ”) and the above“ Session type ”(Session type TLV),“ Application type ”(Application type TLV),“ Session name ”(Session name TLV), and“ Provisioning information ” (Each information of “Provisioning information TLV” can be set.
  • the provisioning message includes a message type field 81 indicating the message type S (in this case, “provisioning”), a message length field 82 indicating the length of the message, a message ID field 83, and the provisioning.
  • provisioning information TLV provisioning information
  • provisioning information is exchanged using an LDP address message (a message exchanged after LDP is established), for example, as shown in Fig. 14, the message type (in this case, ⁇ Address (Address) ) J is displayed) Message type field 9 1, message length field 9 2 indicating the length of the message, message ID field 9 3, address list (Address List) TLV field 9 4, optional parameter field 9
  • the parameter to be set in the optional parameter field 95 of the address message having 5 is extended so that “Provisioning information TLV” can be set as provisioning information.
  • the provisioning information of the remote (remote) side is automatically obtained (or deleted (withdrawn)) as appropriate, and an incorrect wiring and / or a setting error of the provisioning information is detected. It becomes possible.
  • the exchange of the provisioning information may be performed using one of the initialization message and the address message, or may be performed using both of them.
  • the hello messages are exchanged by the function of the label distribution signaling processing sections 118 (step S 1).
  • the LSR # 1-LSR # 2 Multiple LDP sessions can be explicitly specified and identified.
  • assigning the session ID to all the messages shown in Fig. 15 in adjacent LSR # 1 and LSR # 2 multiple LDP sessions using the same label space can be established. .
  • the hello message includes the “session type TLV” and / or the “application type TLVj and / or the“ session name ”.
  • TLVJ By assigning TLVJ, it is possible to explicitly specify and identify the application that uses the LDP session to be established and Z or its use, and to establish a hello neighbor that clearly indicates the application and Z or its use. It can be established correctly (step S 2).
  • the function of the label distribution signaling processing unit 118 (function as a tunnel LSP setting unit for setting a tunnel LSP with an adjacent LSR in advance) allows the adjacent LSR (PE)
  • PE adjacent LSR
  • a full-mesh LSP tunnel LSP is set up between normal LSPs and normal LSPs are connected directly between adjacent LSRs 11 (this allows the use of the basic discovery mechanism using tunnel LSPs).
  • the transport connection is established between the adjacent LSR # 1 and LSR # 2 by exchanging TCP messages (steps S3 to S5) (step S6). ),
  • the initialization messages are exchanged by the functions of the label distribution signaling processing sections 118 (steps S7, S8).
  • the initialization message by extending the initialization message with items 3>, ⁇ 4>, ⁇ 5>, ⁇ 7>, and ⁇ 8> as described above, It is possible to explicitly specify and identify the application that uses the LDP session and / or its use.
  • the “Provisioning TLV” is added to the above-mentioned initialization message to exchange the provisioning information, so that the MPLS processing unit 11 1 In 5, it becomes possible to obtain [or delete (withdraw)] the provisioning information on the remote side, check out the unmatching of the provisioning information, and notify the maintenance person or the like. Also, it is not necessary to set the address of the remote even.
  • the MPLS processing unit 115 detects an unmatch in the provisioning information, the subsequent processing may be continued or stopped. Depending on the information to be exchanged, a new TLV may be added to the address message.
  • the provisioning message is newly defined and the ⁇ provisioning information TLV '' is added.
  • the provisioning message is added between the adjacent LSR # 1 and LSR # 2 after the LDP session is established. After the LDP session is established, it is possible to obtain (or delete (withdraw)) the provisioning information on the remote side even after establishing the LDP session, and to check out the mismatch of the provisioning information and notify the maintenance person etc. . In this case as well, the subsequent processing may be continued or stopped.
  • the adjacent LSR # 1-LS R2 respectively receives the session parameters of the initialization message. If the data is permitted, a keep-alive message is issued periodically to notify the remote side that it is operating normally (steps S11 and S12). As described above, between the adjacent LSR # 1 and LSR # 2, a plurality of LDP sessions using the same label space are correctly established by the application using the session and Z or its use.
  • the adjacent LSR # 1-LSR # 2 exchanges the address of the LDP peer used for the forwarding decision of the MPLS packet (labeled packet) by an address message (step S14).
  • the provisioning information on the remote side is obtained [or deleted (retracted) as in the case of using the initialization message.
  • the processing after the unmatch is detected may be continued or may be stopped.
  • the “Provisioning information TLV” may be added to the initialization message.
  • the adjacent LSR # 1 to LSR # 2 transmit and receive a label mapping message based on the information content of the mutually received address message to perform label distribution (label mapping) (steps S15 and S16). ).
  • label mapping label mapping
  • the LDP session can be connected without error, and erroneous porting and erroneous connection of the session can be detected early when the session is established.
  • MPLS and application malfunctions due to provisioning errors and automatically detects provisioning information on remote LSRs, eliminates (or reduces) provisioning of remote side information, and incorrectly connects or malfunctions due to provisioning jungle mistakes. Can also be reduced. Therefore, in a network composed of MPLS and Z or GMPLS and / or equipment that implements the protocol extended from the former (packet relay equipment ZTDM relay equipment Z optical wavelength repeater, etc.), MPLS and / or GMPLS and Z or the former should be used. When implementing applications using the extended protocol, it is expected that network design will be easier, more flexible, and maintenance / operation will be more efficient.
  • simplification of label switch network design, improvement of flexibility and improvement of Z operation / management efficiency can be expected, and devices having functional limitations or functionally limited devices can be expected. It can be expected to improve interoperability between devices with restrictions and devices equipped with general-purpose functions, and is considered to be extremely useful in the network communication field.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

MPLS等のラベルスイッチネットワーク（１）において、ラベル配付プロトコルにより隣接ラベルスイッチノード（１１）間で送受されるメッセージに、当該ノード（１１）間に確立すべきセッションを識別するセッション識別情報を付加してメッセージの送受を行ない、当該ノード（１１）が、それぞれ、上記セッション識別情報に基づいて、同一隣接ラベルスイッチノード（１１）間に同一ラベル空間で使用する複数セッションを確立する。これにより、ラベルスイッチネットワーク（１）の設計の容易化，柔軟性向上及び保守／運用／管理効率などの向上が期待できる。

Description

明 細 書 ラベルスィツチネットワークにおけるセッション確立方法
及び
ラベルスィッチノード 技術分野
本発明は、 ラベルスィツチネットワークにおけるセッション確立方法及びラベ ルスイッチノードに関し、 特に、 MPLS (Multi Protocol Label Switching) やこ れを拡張したプロトコルを採用するネットワークやノードに用いて好適な技術に 関する。 背景技術
従来、 限定された地域内での高品質な映像の実時間性を満たした通信並びに大 容量データの高速転送を可能にする技術として、 例えば、 特開 2 0 0 0— 2 3 2 4 5 4号公報 （以下、 特許文献 1という） により提案されているもの （地域限定 型高速通信システム及びサービス実現方法) がある。 この特許文献 1の技術は、 ギガビット LAN (Local Area Network)等の周知の高速 LAN技術を用いた地域 限定型高速通信システムであり、 通信フレームに限定された地域を特定する地域 ID情報及びユーザの業種を特定する業界 ID情報並びにユーザを特定するユーザ ID情報を含む通信フレームを用いてデータ転送を行なうことにより、高品質な映 像を使用するユーザを対象とした限定された地域内のユーザ間で高速なデータ通 信を行なうものである。
これに対し、 近年、 従来のルータでは実現が困難であったパケット転送経路の 明示的な指定を可能とし、 経路の偏りを防いでリンクの使用効率を高めたり、 ィ ンターネット上で IP-VPN (Internet Protocol- Virtual Private Network) を実現 したりするために、 MPLSが利用されるようになつてきており、その研究 ·開発' 改良 （拡張） 等も盛んに行なわれている。
ここで、 MPLSは、 IPパケットのルーテイングを IPへッダの代わりに 「ラベ ノレ」 と呼ばれる短い固定長の経路識別情報を利用して行なう技術であり、 MPLS をサポートするルータ 〔一般に、 LSR (Label Switching Router) と呼ばれる〕 同士が所定のラベル配付プロトコル （LDP： Label Distribution Protocol) によ り、 必要な 「ラベル」 を交換することが行なわれる。.
また、近年では、当該 MPLSの拡張版として、 「ラベル」に TDM(Time Division Multiplexing) のタイムスロットやフォトニックネットワークの光波長 ( 1 ) を 用いる G (Generalized) MPLS [MP(l )S とも呼ばれる〕 を実装する装置 （パ ケット中継装置， TDM 中継装置， 光波長中継装置等） や、 これを用いて構成し たネットワークやアプリケーション [MPLS L2 (Layer 2) VPN, MPLS L3 (Layer 3) VPN, MPLS-TE (Traffic Engineering), GMPLS等〕 も開発されて いる。 以下、 MPLS技術の概要について説明する。
〔1〕 ラベル配付プロトコル （LDP： Label Distribution Protocol) の識別 EFC (Request For Comments) 3036(LDP Specification) (非特許文献 1 ) の 2.2.2項に記述されているように、 LDP識別子は、 全体が LSROLabel Switching Router)識別子 （LSR ID) ( 4オクテット） 及びラベル空間識別子 （Label space ID) ( 2オクテット） の計 6オクテットで構成され、 P粦接 LSR間の LDPセッシ ョンを識別するとともに、 その LSRが送信するラベル空間を識別するものであ る。 ここで、 「LSR識別子」 は、 LSRを識別するグローバルな値で、 通常は、 ル ータ IDを使用することが推奨されている。 また、 「ラベル空間識別子」 は、 LSR 内で使用されるラベル空間を識別する値である。
そして、 「ラベル空間 （Label space )」 と しては、 「 per interface」 と 「plaば orm-wide」 とが規定されており、 後者の 「plaば orm_wide」 を使用する場 合はラベル空間識別子 = 0とすることが規定されている。
したがって、 同一隣接 LSR間で同一ラベル空間を使用した LDPセッションを 複数設定することはできない （LSR識別子を変更すれば可能ではあるが、 この場 合は論理的に LSRを分けなければならないことになる）。
〔2〕 基本ディスカバリメカニズムと拡張ディスカバリメカニズム
次に、 基本ディスカバリメカニズムと拡張ディスカバリメカニズムの用途と概 要について説明する。 まず、 前者の 「基本ディスカバリメカニズム」 は、 直接 （物理的に） 接続され た隣接 LSRを自動検出し、 ハロー （Hello) 隣接を確立するために用いられるも のであり、 後者の 「拡張ディスカバリメカニズム」 は、 直接接続されていない隣 接 LSRを検出し、 ハロー隣接を確立するために用いられるものである。
そして、 「基本デイス力バリメカニズム」 では、 宛先 IPァドレスをマルチキヤ ストアドレス (224.0.0.2)としたハローメッセージ（Hello Message)を UDP (User Datagram Protocol)パケットにて送信することにより、 Hello隣接を自動検出す る （隣接 LSRからの Hello Messageの受信により検出する）。 したがって、 「基 本デイス力バリメカニズム」では、ハロ一隣接確立のためのプロビジョニング（事 前設定） が不要である。 なお、 ハローメッセージの送信元 IP アドレスには、 自 インタフェースの IP アドレスを用いるが、 具体的に何を使うかは、 実装事項で ある （例えば、 当該インタフェースアドレスやループバックアドレス、 LDPセッ ション専用ァドレス等を用いることができる）。
これに対し、 「拡張ディスカバリメカニズム」 では、 宛先 IPァドレスを特定の ュニキャスト IPァドレスとしたハローメッセ一ジを UDPバケツトにて送信する ことにより、 直接接続されていない隣接 LSH を検出して、 ハロー隣接を確立す る。 したがって、 「拡張ディスカバリメカニズム」 では、 ハロー隣接確立のための プロビジョエングが必要となる。 なお、 この場合も、 送信元 IP アドレスには、 自装置の IPアドレス （具体的に何を使うかは、 実装事項） を用いる。
〔3〕 LDPセッション確立シーケンス
次に、 LDPセッションの確立手順について、 図 1 6を参照しながら説明する。 この図 1 6に示すように、 LDPでは、 隣接 LSR#1-LSR#2間において、 まず、 ハ ローメッセージを送受信して (ステップ A 1 )、 Hello隣接を確立した後 (ステツ プ A 2 )、 TCP (Transmission Control Protocol) メッセージの送受信を行なう (ステップ A 3 , A 4 , A 5 ) ことで、 トランスポートコネクション （TCP) を 確立し （ステップ A 6 ) 、さらに、 ィニシャライゼーシヨンメ ッセージ (Initialization Message)を送受信して互いに所定のセッションパラメータを許 容した後、 定期的にキープアライブメッセージ （Keep Alive Message) を送受信 する （ステップ A 7〜A 1 2 ) ことによって、 LDPセッションを確立する （ステ ップ A 1 3 )。
LDPセッションが確立した後は、 LSR#1-LSR#2間において、 さらに MPLS バケツト （ラベル付きパケット） のフォヮ一ディングデシジョンに使用する LDP ピアのアドレスをアドレスメッセージ （Address Message) によって交換し、 当 該ァドレスメッセージに基づいてラベルマツピングメッセージ (Label Mapping Message) を送受してラベル配付 (ラベルマッピング） を行なう (ステップ A 1 4〜A 1 6 ) ことにより、 各 LSR#1, LSR#2において、 配付されたラベルを付 加された MPLSバケツトのフォヮーディングが可能となる。
なお、 現状では、 後述するラベル広告モードのアンマッチは、 上記ィニシャラ ィゼーシヨンの交換まで分からない (検出できない）。
〔4〕 rMartiniJ 方式の MPLS L2 VPN
次に、 MPLS L2 VPN(Virtual Private Network)の 1つである 「Martini」 方 式 〔MPLSを使用し L2 (Layer 2)で仮想専用線 （PW： pseudo wire) を提供す る方式〕 では、 新しく Forvvarding Equivalence Class (FEC)j タイプとして rpw FEC element] とそれに対応する PW 〔旧名称は VC(Virtual Channel)] TLV (TVpe/Length Value)を追加定義しているが、 その他は基本的に LDPを使 用する。 具体的には、 rdownstream unsolicited] モードと拡張ディスカバリメ 力二ズムを使用する。 なお、 「Martini」 方式の最新版は、 後記の非特許文献 2及 び 3等として IETF (Internet Engineering Task Force) の pvve3 WG (Pseud o Wire Emulation Edge to Edge Working Group) の WG ドラフトとなって おり、 標準化予定である。
以下、 「Martini」 方式の概要を LDPセッションの確立及び LSP (Label Switched Path)の確立という観点から図 1 7に示すネットワーク構成例を用レヽ て説明する。 なお、 この図 1 7において、 PE#1， PE#2, PE#3はそれぞれ他ネ ットワークと接続するプロバイダェッジ （Provider Edge) と呼ばれる LSR、 コ 了 (Core) LSRはそれ以外の LSRを表し、 PE#1はコア LSRと、 PE#2はコア LSR及ぴ PE#3と、 PE#3はコア LSRと PE#2とそれぞれ物理的に接続 （実線 表示） されている。
[LDPセッションの確立] (1)制御メッセージの通信経路の確立
下記の項目（2)以降で示される LDPセッションの確立及び LSPの確立のために は、 OSPF (Open Shortest Path First), LDP等の制御メッセージが全ての LSR CPE, コア LSR〕 で送受信できる必要がある。
ここで、 rMartiniJ ドラフトでは、 その制御メッセージの力プセリングを特に 規定していない。 したがって、 制御メッセージには、 ① TCP/IPそのまま 〔カプ セル化なし： OSPF (Open Shortest Path Fast)-IP， LDP-TCP] の場合、 ②ラベ ル（前もって設定された LSP中を通る） で力プセル化されている場合、 ③その他 LL2TP (Layer 2 tunneling protocol), GRE (Generic Routing Encapsulation) 等〕 の場合が考えられる。
上記②の場合には、 何らかの方法 〔スタティック， LDP, CR (Constraint Ro uted) -LDP, ESVP-TE (Resource Reservation Protocol for traffic engineeri ng)等〕 で LSPを確立する必要がある。
(2)通常の LDPセッションの確立
図 1 8に実線矢印 1 0 0 , 2 0 0 , 3 0 0 , 4 0 0で示すように、 全ての隣接 LSR (PE, コァ LSR) 間で通常の LDPセッションが前記の 「基本デイスカバリ メカニズム J を使用して確立される。
(3) PE間の LDPセッションの確立
図 1 8に点線矢印 5 0 0 , 6 0 0 , 7 0 0で示すように、全ての PE (PE#1-PE#2, PE#1-PE#3, PE#2-PE#3)間にフルメッシュで、 「拡張ディスカバリメカニズム」 を使用して LDPセッションを確立する。この時、それぞれの PE#1， PE#2, PE#3 には、 接続先 （リモート側） の LSRの IPアドレスが全てプロビジョエングされ ている必要がある。
ただし、 この図 1 8中に示す通り、 PE#2-PE#3間は直接接続されており、 LDP セッション 4 0 0が上記 「 (1)制御メッセージの通信経路の確立」 により既に確立 しており、 LDPセッション 7 0 0は新たに設定する必要がなレ、。 また、 RFC3036 の規定では、 厳密には設定できない。 し力 し、 PE#2， PE#3それぞれが互いに隣 接していることを知っていなければ、 このセッションを設定しょうとする。 これ に対しては、 以下①〜③の実装が考えられる。 ①プロビジョユングにより、 隣接していることを明示し、 当該セッション 70 0の設定を行なわない。
② PE#2-PE#3間の通常の LDPセッション 400が既に設定されていることを チェックし、 当該セッシヨン 700の設定を行なわない。
③何もチェックせずに、 当該セッシヨン 700の設定をしょうとするが、 通常 の LDPセッション 400と同一セッシヨンということで、 結果として設定でき なレ、。
ところが、 図 19において、 例えば PE#2-PE#3間のリンクが何らかの理由で 使用不可となつた場合は、 当該 PE#2-PE#3間で 「拡張デイス力バリメカニズム」 を使用して LDPセッションを設定する必要がある。 したがって、 選択枝は、 上 記の②又は③となる。
上述の通り、 「Martini」 方式は、 制御メッセージのカプセリングを規定してい ないので、 もし、 例えば図 20に示すように、 通常の LSP50 OA, 500 B, 60 OA, 600 B, 70 OA, 700 Bが既に設定されている場合は、 当該セ ッシヨン 500, 600, 700は、 その LSP500 A， 500 B, 600 A, 600 B, 70 OA, 70 OB中で設定される （LSPを通して LDPセッション が確立される） 可能性がある （ネットワーク及び装置の実装 Z運用ポリシに依存 する）。
なお、 LSPは片方向の属性をもつので、 この図 20において、 LSP500A及 び 500 Bの組が PE#1-PE#2間の通常の LDPセッション 500、 LSP 60 OA 及び 600 Bの組が PE#1-PE#3間の通常の LDPセッション 600、 LSP 700 A及び 700 Bの組が PE#2-PE#3間の通常の LDPセッシヨン 700をそれぞれ 示している。
[LSPの設定例]
(1)通常の LSPの確立
IP経路に基づき、 通常の LSPが図 21に太実線矢印 50 OA, 500 B, 6 00 A， 600 B, 70 OA, 700 Bで示すように確立される。 ここで、 PE#2 及び PE#3から PE#1に向かう LSP500 B, 600 Bは、 コア LSRでマージ さ; る。 (2)PW用の LSPの確立
： PW用の LSPは、上述の PE間に設定された LDPセッション 500, 600， 700上で、 上述の PW用 FECを付加した 「Label Mapping] メッセージでラ ベルを配付することにより確立される。 ここで、 PWは、 同一 PE間の互いに逆 向きの FW用 LSPのペア（図 21に示す； PWLSP500 a及び 500 b又は PW 用 LSP600 a及ぴ 600 b又は PW用 LSP700 a及び 700 b)力、らなり、 PW用 FEC中の PWIDによって対応付けられる。 この PWIDは、 双方の PE で予めプロビジョニングしておく必要がある。なお、図 21において、 PE#2-PE#3 間の PW用 LSP 700 a, 700 bは、 図示の通り トンネル LSP 70 OA, 7 00 B中を通してもよいし、 トンネル LSP700A, 700 Bとは独立して設定 してもょレ、。もっとも、 トンネノレ LSP700 A， 700 B中を通すことにしても、 PHPを使用すればトンネルラベルは付加されない。
また、 「Martini」方式では、： PW用の LSPのトンネリングに関しても規定して いない。 そこで、 管理 Z運用上 （例えば、 制御メッセージとユーザデータを分離 し管理を容易にする) 又はサービス上 〔例えば、 ユーザデータに関する QoS
(Quality of Service) /CoS (Class of Service)の提供〕の理由からトンネル LSP に関して様々なバリエーンョンが考えられる。以下にそのバリエーションを示す。 なお、 ここでは、詳しく述べないが、 トンネルは LSP以外を用いて設定しても良 レ、。
①通常の LSP中での確立
PE間の LDPセッションを使用して、 F 用 LSPを確立する。 ここで、 PE#1-PE#2間及び PE#1-PE#3間の直接の経路は、 図 21の通常の LSP 500 A， 500 B, 60 OA, 600 B ( 500 B及び 600 Bはコア LSRでマー ジされている） しか存在しないので、 必然的に、 これらの LSP500A, 500 B, 600A, 600 Bをトンネル LSPとして使用することになる。
—方、 PE#2-PE#3間については、 直接の経路として、 IPの経路と通常の LSP 700A, 700 Bとが存在するので、 どちらを使用するかをそのネットワーク または装置の選択ポリシにより決定する必要がある。以下にその特徴を示す。
•容易に LSPの設定が可能 （特別なトンネル LSPの設定の必要がない)。 •制御メッセージとユーザデータが同一トンネル中で混在する可能性がある。
•当該トンネル LSPは、 べストェフォートサービスしか実現できない。
② PW専用 LSP中での確立 （その 1 ：スタティック設定したトンネル LSPで 上述した通常の LSPと同等の LSPをスタティックに設定する。 この場合、 以 下の特徴がある。
• トンネル LSPの設定のために全ての PE及び LSRにプロビジョユングが必 要)。
•制御メッセージとユーザデータの分離が可能。
·経路を IP経路と独立に設定できる。
• QoS/CoSの適用が可能。
③； PW専用 LSP中での確立 （その 2 ： CR-LDP/ESVP-TEで設定したトンネ ル LSPで設定）
上述した通常の LSPと同等の LSPを CR-LDP/RSVP-TEで設定する。 この 場合、 以下の特徴がある。
• トンネル LSPの設定のために全ての PEにプロビジョエングが必要となる。 •制御メッセージとユーザデータの分離が可能。
•経路を IP経路と独立に設定できる。
• QoS/CoSの適用が可能。
④ PW専用 LSP中での確立 （その 3 ： LDPで設定したトンネル LSPで設定） 通常に設定された LSPが; PE間に複数存在する場合に、その中で、使用されな い LSPを PW専用 LSPとして使用する。 この場合、 以下の特徴がある。
•プロビジョユングが不要。
•一般的には使用できない （上記の PE#1-PE#2, PE#1-PE#3のように IP経 路 （または物理的経路） が 1つしか存在しない場合、 同一 FECに対しては複数 の LSPを設定できないため：逆にいえば、 FECを分ければ可能）。
•制御メッセージとユーザデータの分離が可能。
•経路を IP経路と独立に選択できない。
•べストェフォートサービスしか実現できない。 以上から、 既存の MPLSやその拡張方式には、 次のような特徴がある。
(1)制御メッセージの経路 Zカプセリングに様々なバリエーションが存在する (場合によっては何らかのプ口ビジョニングが必要)。
(2) PWが通るトンネル （LSP) にも様々なバリエーションがある （場合によつ ては何らかのプロビジョニングが必要）。
(3)リモート側の LDPセッション用のアドレスをプロビジョニングする必要が ある （リモート側と直接接続していないため）。
(4)リモート側のァドレスとして、誤って rMartiniJ を実装しない LDPェンテ ィティをプロビジョニングしてしまえば、 ラベルマッピングメッセージを送受信 するまでリモート側の LDPエンティティが 「PW FEC element」 を処理できる かどうかが分からない (または、 処理するようにプロビジョユングされているか どうか分からない）。
(5) PW IDは、関係 PE双方でプロビジョユングされ、 ラベルマッピングメッセ ージで通知される。 したがって、 このプロビジョニングの誤りもラベルマツピン グメッセージを送受信するまで分からない (検出できない）。
ところで、主に、 キャリアネットワークで普及している MPLSのシグナリング プロトコル （Signaling protocol) として最も普及している LDP(Label distribu tion protocol)のセッションは、 同一隣接 LSRとの間で複数設定することはでき ない （同じラベル空間を使用している場合） し、 同一隣接 LSR間で設定された L DPセッションを使用するアプリケ一ション又はその用途を明示的に識別するこ ともできなレ、。
したがって、 そのセッションの両端の LDPエンティティが、 rMartiniJ 方式 の拡張を実装しているかどう力 \ または、 実装していてもそれを使用するように プロビジョユングされているかどう力が、 ラベルマッビングのフェーズまで分か らなレ、。 また、 双方が、 「Martini」 方式を実装し、 使用するように設定されてい たとしても、 上記の (1)〜(5)に示す、 「Martini」 方式の MPLS L2 VPNでの各種 プロビジョユング情報が誤っていた場合、 それをプロトコル上で検出できず、 誤 動作するか、 または、 検出できても LDP セッションの確立時に確実に検出する ことはできない。 以下に、 具体例を図 1 7に示すネットワーク構成を参照しながら説明する。
(1)前提条件
① PE#1は、 IPパケット （制御メッセージ） をそのまま送受信できない装置で あり、 MPLSで力プセル化した IPパケットしか送受信できない装置である （ブ リッジベースの装置に rMartiniJ 方式を実装した場合、 ハードウェアの制約及 び又は実装コスト面からこのような実装が考えられる）。 また、 この装置は、上記 LSP以外については、 LDPによって動的に LSPを設定できる能力をもつものと する。
② PE#2, PE#3,コア LSRは、 IPバケツトをそのまま送受信可能であり、 MPLS でカプセルィヒした IPバケツトも送受信可能である。
③ネットワークの運用ボリシとして、 制御メッセージは、 LSP 中で送受信し、 さらに、 PW用トンネル LSPと前記制御メッセージ用 LSPを分離する。
(2)上記の前提条件①，②ょり、 PE#1とコア LSRとの間には制御メッセージ用 の LSPがスタティックに設定される必要がある。 また、 PE#2, PE#3, コア LSR には、制御メッセージを LSP中で送受信するという運用ポリシの設定が必要とな る。 この時、 明示的なプロビジョニング、 または、 IP経路と LSP経路の優先度 の設定などが考えられる。
(3)上記の前提条件③ょり、 制御メッセージ用 LSPとは別に PE#1,PE#2,PE#3 間にフルメッシュで、 PW用のトンネル LSPを設定する必要がある
(4)PE#1, PE#2， PE#3は、 上記 (3)項で設定した LSP中には制御メッセージ を送信してはいけない。
以上のようなネットワーク条件において、 以下の課題がある。
®PE#2, PE#3, コァ LSRに関して、 制御メッセージを LSP中で送受信する という運用ポリシの設定が誤つていると、 PE#2-PE#3間の LDPセッションは確 立されるが、 ΡΕ#1-ΡΕ#2, ΡΕ#1-ΡΕ#3, ΡΕ#2·ΡΕ#3間の全て、 又はいずれかの
LDPセッションが確立されない。
(DPE#1, PE#2, PE#3 に関して、 PW用トンネル LSP と制御メッセージ用
LSPを分離するというポリシの設定が誤っていると、 PW用トンネル LSPが設 定できなかつたり、： PW用トンネル LSPが設定できても、その両端で認識がずれ て、一方は制御メッセージ用の LSPを使用して PW用 LSPを設定し、他方は FW 用トンネル LSPを使用して； PW用 LSPを設定してしまレ、、 結果として、 正常に PW中のフレームが処理されなかったりする場合がある。
(3)PE#1-PE#2, PE#1-PE#3, PE#2-PE#3間の LDPセッション設定時にリモ 一ト側のァドレスのプロビジョユングが誤っていると、 当該 LDPセッションが 設定されない。 または、 実装によっては、 LDPセッション自体は設定される力 当該セッションを使用して F LSPが設定されない。
④ PE#1-PE#2， PE#1-PE#3, PE#2-PE#3間それぞれの PW IDのプロビジョ ニングに誤りがあれば、 PWが正しく設定されない。 そして、 それは、 LDPでは ラベノレマッビングのフエ一ズまで分からない。
一方、 MPLSのアプリケーションは LDPを拡張し、または、そのまま使用し、 続々と標準化され、 また、 独自に開発されている。 ここで、 そのアプリケーショ ンによっては、 同一 LDP セッションを利用することができないものがある。 例 えば、 LDP のラベノレ広告モード力 S 「 Downstream Unsolicited J モー ドと 「Downstream on Demandj では互換性がないので、アブリケ一ションがそれぞ れ別のモードを使用する場合は同一 LDP セッションを使用することができない し、 プロトコルとしては、 同一 LDPセッションを利用することができても、 管 理， 運用， 保守の側面から、 アプリケーション及び/又はその用途毎に LDPセ ッションを分離することが望まれることがある。
例えば、 トラヒックエンジニアリングと iMartiniJ 方式とをそれぞれ実装し ようとしても、 トラヒックエンジニアリングは通常 「Downsti'eam on Demandj を使用し、 「Martini」 方式は、 「Downstream UnsolicitecU モードを使用するの で、 実装できない。 また、例えば 「Martini」 方式の実装において、 管理， 運用， 保守の側面から制御メッセージ用の LSP トンネルと PW用の LSP トンネルを、 LDPを使用して独立に設定しようとしてもできない。 · 特許文献 1
特開 2 0 0 0— 2 3 2 4 5 4号
非特許文献 1 L. Andersson et al" "LDP specification" (Request for Comments), [online], January 2003, Network Working Group Internet Draft of IETF [平成 15年 6 月 16日検索]、 インターネットく http:〃www.iet£org/rfc/rfc3036.txt >.
非特許文献 2
Luca Martini et al., Transport of Layer 2 Frames Over MPLS (draft-ietf-pwe3-control-protocol-01.txt), November 2002， Network Working Group Internet Draft oi Internet Engineering Task Force (IETF).
非特許文献 3
Luca Martini et al" "Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks (draft-ietf-pwe3-ethernet-encap-02.txt), [online], February 2003, Network Working Group Internet Draft of IETF [平成 15年 6月 16日検索]、 ィンターネットく URL： http://www.ietf.org/inter net-drafts/draft-ietf-pwe3-ethernet-encap-02.txt >. 本発明は、 以上のような課題に鑑み創案されたもので、 同一隣接 LSR 間で、 同じラベル空間を使用した LDPセッションを複数設定することを可能とし、 ま た、 そのセッションを使用するアプリケーション及び/又はその用途を明示的に 示すことを可能とし、 LDPセッションを誤りなく接続することにより、誤プロビ ジョニング及び/又はこれによるセッションの誤接続をセッション確立時に早期 に検出できるようにすることを目的とする。
また、プロビジョニングの誤りによる MPLS及びアブリケーションの誤動作を 防止し、 さらに、 リモート側 LSRに関するプロビジョニング情報を自動検出し、 リモート側情報のプロビジョユングを無くし （あるいは減らし）. て、 プロビジョ ユングミスによる誤接続又は誤動作を削減することも目的とする。 発明の開示 '
上記の目的を達成するために、 本発明のラベルスイッチネットワークにおける セッション確立方法は、 所定のラベル配付プ口トコノレにより配付されたラベル情 報に従って受信バケツトをルーティングする機能を有する複数のラベルスィツチ ノードをそなえて成るラベルスィッチネットワークにおいて、 該ラベル配付プロ トコノレにより隣接ラベルスィツチノード間で送受されるメッセージに、 同一隣接 ラベルスイッチノード間に確立すベきセッションを識別するセッション識別情報 を付加して該メッセージの送受を行ない、 同一隣接ラベルスィッチノードが、 そ れぞれ、 該セッション識別情報に基づいて、 該同一隣接ラベルスィツチノード間 に同一ラベル空間で使用する複数のセッションを確立することを特徴としている。 また、 本発明のラベルスイッチネッ トワークにおけるセッション確立方法は、 所定のラベル配付プロトコルにより配付されたラベル情報に従って受信バケツト をルーティングする機能を有する複数のラベルスイッチノードをそなえて成るラ ベルスィツチネットワークにおいて、 該ラベル配付プロトコノレにより隣接ラベル スィツチノード間で送受されるメッセージに、 該隣接ラベルスィツチノード間で 確立すべきセッションを使用するアプリケーション及びその用途のいずれか一方 又は双方を明示するセッションタイプ情報を付加して該メッセージの送受を行な レ、、 該隣接ラベルスィッチノードが、 それぞれ、 該セッションタイプ情報に基づ いて、 該隣接ラベルスィツチノード間に該セッションタイプ情報に応じた該セッ シヨンを確立することを特徴としている。
さらに、本発明のラベルスィツチネットワークにおけるセッション確立方法は、 所定のラベル配付プロトコルにより配付されたラベル情報に従って受信バケツト をルーティングする機能を有する複数のラベルスィツチノードをそなえて成るラ ベルスィツチネットワークにおいて、 該ラベル配付プロトコルにより隣接ラベル スィツチノード間で送受されるメッセージに、 同一隣接ラベルスィツチノード間 に確立すベきセッションを識別するセッション識別情報と、 当該セッシヨンを使 用するアプリケーション及ぴその用途のいずれか一方又は双方を明示するセッシ ョンタイプ情報とを付加して該メッセージの送受を行ない、 該同一隣接ラベルス イッチノードが、 それぞれ、 該セッション識別情報及び該セッションタイプ情報 に基づいて、 該同一隣接ラベルスィツチノード間に同一ラベル空間で使用する、 該セッシヨンタイプ情報に応じた複数のセッションを確立することを特徴として レヽる。
ここで、 該メッセージとしてのハローメッセージに該セッションタイプ情報を 付加することにより、 該隣接ラベルスイッチノード間のハロ一隣接確立時に該セ ッションタイプ情報を該隣接ラベ スィツチノード間で交換するようにしてもよ いし、 該メッセージとしてのィニシャライゼーションメッセージに、 該セッショ ンタイプ情報を付加することにより、 該隣接ラベルスィッチノード間のセッショ ン確立時に該セッシヨンタイプ情報を該隣接ラベルスイッチノード間で交換する ようにしてもよい。
また、 隣接ラベルスィッチノード間で該セッションを確立する際に、 該ラベル 配付プロトコルのエンティティに関するプロビジョニング情報を該メッセージに 付加して交換するようにしてもよい。
さらに、 本発明のラベルスィッチノードは、 所定のラベル配付プロ トコルによ り配付されたラベル情報に従つて受信パケットをノレ一ティングする機能を有する ものであって、 該ラベル配付プロトコルにより隣接ラベルスィッチノードとの間 で送受すべきメッセージに、 同一隣接ラベルスィツチノード間に確立すべきセッ ションを識別するセッション識別情報を付加して該メッセージの送受を行なうラ ベル配付プロ トコル処理部と、 該ラベル配付プロ トコル処理部で該隣接ラベルス ィツチノードから受信した該ラベル配付プロトコルのメッセージに付加されたセ ッション識別情報に基づいて、 該隣接ラベルスイッチノードとの間に同一ラベル 空間で使用する複数セッションの確立を制御するセッション確立制御部とをそな えたことを特徴としている。
また、 本発明のラベルスィッチノードは、 所定のラベル配付プロトコルにより 配付されたラベル情報に従って受信パケットをルーティングする機能を有するも のであって、 該ラベル配付プロ トコノレにより隣接ラベルスィツチノードとの間で 送受すべきメッセージに、 該隣接ラベルスィツチノードとの間で確立すべきセッ シヨンを使用するアプリケーション及びその用途のいずれか一方又は双方を明示 するセッションタイプ情報を付カ卩して該メッセージの送受を行なうラベル配付プ 口トコル処理部と、 該ラベル配付プ口トコル処理部で該隣接ラベルスイッチノー ドから受信した該ラベル配付プ口トコルのメッセ一ジに付加されたセッションタ イブ情報に基づいて、 該隣接ラベルスィツチノードとの間に該セッションタイプ 情報に応じた該セッションの確立を制御するセッション確立制御部とをそなえた ことを特徴としている。
さらに、 本発明のラベルスィッチノードは、 所定のラベル配付プロ トコルによ り配付されたラベル情報に従って受信バケツトをルーティングする機能を有する ものであって、 該ラベル配付プロトコルにより隣接ラベルスィツチノードとの間 で送受すベきメッセージに、 該隣接ラベルスィツチノードとの間に確立すベきセ ッションを識別するセッション識別情報と、 当該セッションを使用するアプリケ ——ンョン及びその用途のレ、ずれか一方又は双方を明示するセッションタイプ情報 とを付加して該メッセージの送受を行なうラベル配付プロトコル処理部と、 該ラ ベル配付プロトコル処理部で該隣接ラベルスィツチノードから受信した該ラベル 配付プ口トコルのメッセ一ジに付加されたセッション識別情報及びセッシヨンタ ィプ情報に基づレ、て、 該隣接ラベルスイッチノードとの間に同一ラベル空間で使 用する、 該セッシヨンタイプ情報に応じた複数セッシヨンの確立を制御するセッ ション確立制御部とをそなえたことを特徴としている。
ここで、 該ラベル配付プロトコル処理部は、 該ラベル配付プロトコルの該メッ セージとしてのハローメッセージに該セッションタィプ情報を付加することによ り、 該隣接ラベルスイッチノードとの間のハロ一隣接確立時に該セッシヨンタイ プ情報を該隣接ラベルスィツチノードとの間で交換するハローメッセ一ジ処理部 をそなえて構成してもよい。
また、 該ラベル配付プロ トコル処理部は、 該ラベル配付プロ トコルの該メッセ ージとしてのィニシャライゼーションメッセージに、 該セッシヨンタイプ情報を 付加することにより、 該隣接ラベルスィッチノードとの間のセッション確立時に 該セッシヨンタイプ情報を該隣接ラベルスイッチノードとの間で交換するィニシ ャライゼーションメッセージ処理部をそなえて構成してもよい。
さらに、 該ラベル配付プロ トコル処理部は、 該ラベル配付プロトコルのェンテ ィティに関するプロビジョニング情報を該メッセ一ジに付加して交換するプロビ ジョニング情報交換処理部をそなえて構成してもよい。
また、 該ラベル配付プロトコル処理部は、 該隣接ラベルスィッチノードとの間 で該セッション確立制御部により該セッションを確立する際に、 予め当該隣接ラ ベルスィッチノ一ドとの間にトンネルラベルスィツチパスを設定するトンネルラ ベルスィツチパス設定部をそなえていてもよく、 この場合、 該プロビジョエング 情報交換処理部は、 該トンネルラベルスィツチパス設定部により設定された該ト ンネルラベルスィツチパスを通じて該プロビジョニング情報の付加された該メッ セージを交換するように構成してもよい。
さらに、 該プロビジョニング情報交換処理部は、 該隣接ラベルスィッチノード 間で該ラベル配付プロトコルに従って送受するィニシャライゼーションメッセー ジ及ぴァドレスメッセージのいずれか一方又は双方に、 該プロビジョニング情報 を転送する TLVを追加するように構成してもよい。
また、 該プロビジョニング情報交換処理部は、 該ラベル配付プロトコルにおい て新規に定義した該プロビジョニング情報の転送用のメッセージを生成するよう に構成してもよいし、 該ラベル配付プロトコルにおいて新規に定義した該プロビ ジョニング情報の撤回用のメッセージを生成するように構成してもよレ、。 図面の簡単な説明
図 1は本発明の一実施形態としての MPLS網 (ラベルスィツチネットワーク) の構成を示す図である。
図 2は本実施形態の LSRの構成を示す機能プロック図である。
図 3は本実施形態の LDP PDUの拡張例を説明するための図である。
図 4は本実施形態のセッシヨンタイプ (Session TYPE) TLVの新規定義例を 説明するためのフォーマット図である。
図 5は本実施形態のアプリケーションタイプ (Application TYPE) TLVの新 規定義例を説明するためのフォーマツト図である。
図 6は本実施形態のセッション名 （Session Name) TLVの新規定義例を説明 するためのフォーマツト図である。
図 7は本実施形態のハローメッセージ （Hello Message) の拡張例を説明する ためのフォーマツト図である。
図 8は本実施形態の共通ハローパラメータ （Common Hello Parameters) TLV を説明するためのフォーマツト図である。
図 9は本実施形態のィニシャライゼーシヨ ンメ ッセージ (Initialization Message) の拡張例 1を説明するためのフォーマット図である。
図 1 0は本実施形態の共通セッションパラメータ （Common Session Parameters) TLVを説明するためのフォ一マット図である。
図 1 1は本実施形態のプロビジョユング情報（Provisioning Information) TLV の新規定義例を説明するためのフォーマット図である。
図 1 2は本実施形態の PWパラメータ （Pseudo Wire parameter) TLVを説明 するためのフォーマツト図である。
図 1 3は本実施形態のプロビジョニングメッセージ (Provisioning Message) の新規追加例を説明するためのフォーマット図である。
図 1 4は本実施形態のァドレスメッセージ (Address Message) の拡張例を説 明するためのフォーマツト図である。
図 1 5は本実施形態の MPLS網における LDPセッション確立手順を説明する ためのシーケンス図である。
図 1 6は従来の MPLS網における LDPセッション確立手順を説明するための シーケンス図である。
図 1 7〜図 2 1はそれぞれ従来の rMartiniJ方式の LDPセッション及び LSP の確立を説明するためのネットワーク構成例を示す図である。 発明を実施するための最良の形態
以下、 本発明の実施の形態について、 図面を用いて説明する。
図 1は本発明の一実施形態としての MPLS網 (ラベルスイッチネットワーク） の構成を示す図で、 この図 1に示す MPLS網 1は、 MPLS機能をサポートする 複数のラベルスィツチノードとしての LSR 1 1がメッシュ状に相互に接続され て構築されている。 そして、 この MPLS網 1には、 外部網 2 , 3 , 4を構成する 通常のルータ (又は、 ブリッジ） 2 1 , 3 1 , 4 1を介して当該外部網 2 , 3， 4と接続されている。 なお、外部網 2 , 3 , 4 〔ルータ （又は、 ブリッジ） 2 1 , 3 1 , 4 1〕 との接続部分に位置する LSR 1 1は特に LER (Label Edge Router) (IP-VPNでの PEに相当する） と呼ばれ、 それ以外の LSR 1 1がコア LSRと 呼ばれる。 このようなネットワーク構成において、本実施形態では、（1)同一隣接 LSR 1 1 間で複数の LDPセッションの確立を可能とするとともに、（2)LDPセッションの アプリケーション及び/又は用途を明確に識別できるようにし、 また、 （3)LSR 1 1のプロビジョニング情報の自動検出を可能とし、 プロビジョニング情報の誤り による誤配線 （誤接続） 及ぴ Z又はプロビジョユング情報の設定ミスを検出でき るようになっている。
このため、 本実施形態の LSR 1 1は、 それぞれ、 その要部に着目すると、 例え ば図 2に示すように、 MPLS L2 VPN アプリケーション部 1 1 1， トラヒックェ ンジニアリングァプリケーション部 1 1 2 , CL/NMS インタフェース部 1 1 3， プロビジョユング情報管理部 1 1 4 , MPLS処理部 1 1 5， IPルーティング処理 部 1 1 6， トポロジー情報管理部 1 1 7 , ラベル配付用シグナリング処理部 1 1 8 , ラベル管理部 1 1 9， MAC フィルタリングデータベース処理部 1 2 0 , ラ ベルスィツチング処理部 1 2 1 , スィツチ制御部 1 2 2及び回線ィンタフェース 部 1 2 3などをそなえて構成されている。 なお、 この図 2において、 実線で示す ラインはこれらの機能ブロック間のインタフェースを表し、 点線矢印で示すライ ンは当該機能ブロック間のデ一タ参照 (アクセス) 経路を表している。
ここで、 MPLS L2 VPN アプリケーション部 1 1 1は、 プロビジョユング情報 管理部 1 1 4が管理するプロビジョニング情報 （Provisioning Information) に 従って、 MPLS処理部 1 1 5に対して、 必要に応じてラベル配付用シダナリング のセッションの確立 Z解放、 トンネル LSPの確立/解放、 PW LSPの確立 Z解 放及び当該トンネル LSPと PW LSPとのマッピング及び/又は当該 PW LSPと アタッチメントサーキットとのマッビング等を指示するためのもので、 本実施形 態では、 以下のような機能拡張を行なっている。
(1)ラベル配付用シダナリング （LDP) のセッションの確立指示時に当該セッシ ヨンを識別するためのセッション識別情報 （セッシヨン ID) を付加する。 本セッ シヨン ID は当該アプリケーション部 1 1 1で自動生成しても良いし、 プロビジ ョニング （プロビジョユング情報管理部 1 1 4で管理） しても良い。
(2)ラベル配付用シグナリングのセッションの確立指示時にリモート側のプロ ビジョニング情報の取得指示を追加する。 (3)ラベル配付用シグナリングのセッションの確立指示時にリモート側装置の プロビジョユング情報と当該装置のプロビジョニング情報のチヱック指示を追カロ する。 さらに、 チェック結果にしたがって、 当該セッションの確立 Z解放を判断 する。
また、 トラヒックエンジニアリングアプリケーション部 1 1 2は、 プロビジョ ユング情報管理部 1 1 4が管理するプロビジョニング情報に従って、 MPLS処理 部 1 1 5に対して、 必要に応じてラベル配付用シグナリングのセッションの確立 Z解放、負荷分散用 LSPの確立 Z解放、負荷分散パラメータの指示（マッピング する複数の LSP, 負荷分散上限閾値， 負荷分散上限閾値等） を行なうためのもの で、 本実施形態では、 ラベル配付用シグナリングのセッションの確立指示時にセ ッシヨン IDを付加できるよう機能拡張している。 なお、本セッシヨン IDも当該 アプリケーション部 1 1 2で自動生成しても良いし、 プロビジョニングしても良 レ、。
さらに、 CL/NMSインタフェース部 1 1 3は、 CL (コマンドライン)及び/又は NMS (ネッ トワーク管理システム)とのインタフェースを司るもので、ここでは、 プロビジョユング情報管理部 1 1 4と連携して、 管理情報の設定及び表示等を行 なう機能を有している。 また、 プロビジョニング情報管理部 1 1 4は、 この CL/NMSインタフェース部 1 1 3からの指示に従い、プロビジョニング情報を設 定 /表示すると共に当該プロビジョユング情報を各機能プロックに対して参照可 能とするものである。 なお、 リモート側プロビジョニング情報に関しては、 対応 機能プロックからの設定も可能としても良い （管理対象としても良い）。
MPLS処理部 1 1 5は、 各種アプリケーション （ここでは、 MPLS L2 VPN アプリケーション部 1 1 1及びトラヒックエンジニアリングアプリケーション部 1 1 2 ) からの指示に従い、 ラベル配付用シグナリングのセッションの確立/解 放、 各種 LSPの確立/解放をラベル配付用シグナリング処理部 1 1 8に指示し、 又は、 リモート側 LSR からのラベル配付用シグナリングのセッションの確立/ 解放、各種 LSPの確立/解放要求を、 ラベル配付用シグナリング処理部 1 1 8を 経由して受信するものである。 また、 当該 LSPの確立 Z解放及びアプリケーショ ンからの指示パラメータに従って、 ラベルスィツチング処理部 1 2 1に対して、 ラベルフォヮ一ディングテーブルの設定 Z変更/解放等を指示する機能も有する。 つまり、 この MPLS処理部 1 1 5は、後述するラベル配付用シグナリング処理 部 1 1 8経由で隣接 LSR から受信するラベル配付用シグナリングメッセージ (LDPメッセージ） に応じて必要な LDPセッションの確立を制御するセッショ ン確立制御部としての機能を果たすものである。ただし、本実施形態においては、 下記のような機能拡張も行なっている。
(1)ラベル配付用シグナリングのセッションの確立指示時にセッシヨン IDを付 加する。
(2)ラベル配付用シグナリングのセッションの確立指示時にリモート （相手） 側 装置 （LSR) のプロビジョユング情報の取得指示を追加する。
(3)上記リモート側装置のプ口ビジョニング情報を必要に応じてチェックし、 そ の結果を指定アプリケーションに通知し、 その後の指示を仰ぐ。
次に、 IPルーティング処理部 1 1 6は、 トポロジー情報管理部 1 1 7と連携し て、 IPルーティングプロトコルを実行することにより、ネットワーク 1の動的な トポロジー情報を維持するものであり、 トポロジー情報管理部 1 1 7は、 当該 IP ルーチング処理部 1 1 6と連携して、 ネットワークの動的なトポロジー情報を維 持 ·管理するとともに、 当該トポロジー情報及びその変化を必要な機能プロック に対して提供するものである。
ラベル配付用シグナリング処理部 （ラベル配付プロトコル処理部） 1 1 8は、 MPLS処理部 1 1 5力、らの指示により、 ラベル配付用シグナリングのセッシヨン の確立/解放、各種 LSPの確立/解放を実施するとともに、 リモート側装置から のラベル配付用シグナリングのセッションの確立 Z解放、各種 LSPの確立 Z解放 要求を MPLS処理部 1 1 5に通知し、その後の処理の指示を仰ぐもので、 ここで は、 LDPメッセージを拡張して、 上記セッシヨン IDや、 確立する LDPセッシ ョンのアプリケーション及びその用途のいずれか一方又は双方を明示する情報 (セッションタイプ情報）、 プロビジョニング情報等を付与 ·交換できるように 種々の機能拡張 （LDPの拡張：詳細は後述） を行なっている。
ラベル管理部 1 1 9は、 上記ラベル配付用シグナリング処理部 1 1 8に対して 自装置が割り当てるラベルの空塞管理機能を提供するものであり、 MAC (Media Access Control) フィノレタリングデータベース処理部 1 2 0は、 プロビジョニン グ情報管理部 1 1 4及び回線ィンタフェース処理部 1 2 3 (#l〜#m： mは自然 数） と連携して、 MAC フィルタリングデータベースの原本を管理し、 各回線ィ ンタフエ一ス処理部 1 2 3に対して、 必要な MACフィルタリングデータベース を提供するとともにスィツチ制御部 1 2 2に対して、 必要なスィツチングを指示 するためのものである。
ラベルスイッチング処理部 1 2 1は、 MPLS 処理部 1 1 5からの指示に従レ、、 ラベルフォヮ一ディングテ一ブルの原本を管理し、 各回線ィンタフエース処理部 1 2 3に対して、 必要なラベルフォヮ一ディングテーブルを提供するとともにス ィツチ制御部 1 2 2に対して、必要なスィツチングを指示するためのものである。 スィツチ制御部 1 2 2は、 MAC フィルタリングデータベース処理部 1 2 0及 ぴラベルスイッチング処理部 1 2 1からの指示に従い、 各回線インタフェース処 理部 1 2 3及び自装置内の必要な機能ブロックとのスィツチングを行なうための ものであり、 回線インタフェース処理部 1 2 3は、 それぞれ、 1以上の回線 (#1 〜#n) を収容し、 MAC フィルタリングデータベース処理部 1 2 0及ぴラベルス ィツチング処理部 1 2 1からの指示に従い、 MAC フィルタリングデータベース /ラベルフォワーディングテーブル (図示省略) を参照することによるフレーム の送受信を行なうものである。
次に、 以下では、 上述した各種機能拡張の具体例について詳述する。
①まず、 同一隣接 LSR 1 1間で複数の LDPセッションの確立を可能とするた めに、 LDP (RFC3036) を拡張する。 その具体例としては、 以下の <1>及び <2> に示す方式が考えられる。
<1>LDP識別子の拡張 （変更）
LDP PDUのフォーマットは変えずに、 LDP識別子を拡張 （変更） し、 セッシ ョン識別情報 （セッシヨン ID) により同一隣接 LSR 1 1間の複数の LDPセッシ ョンを識別可能とする。
この場合、 LDP識別子は、 RFC3036では、 「LSH ID」 （ 4オクテットで構成さ れる LSRを識別するグ口一バルな値）と、 「Label space ID」 （ 2ビットで構成さ れるラベル空間を識別するための値で、 " 0 " で 「platform-wide」 ラベル空間、 " 1 " で 「per interface」 ラベル空間を表し、 " 3 "， " 4 " はリザーブを表す） と で構成されるが、 1 4ビッ トで構成される 「 Session ID」 を新たに定義し、 rplatform-widej ラベノレ空間ではセッション番号、 「per interface」 ラベル空間 では最初の 1 0ビットを「Interface ID」、残りをセッション番号として表示する。
<2>LDP PDUの拡張
例えば図 3に示すように、 LDP PDUのフォーマットにセッシヨン （Session) IDフィールド 1 2を新たに追加定義する。
②また、 確立する LDP セッションのアプリケーション及びその用途のいずれ か一方又は双方を明示する TLVを LDPメッセージ (例えば、ハローメッセージ) に追加することにより、 ハロー隣接確立時にそのセッションのアプリケーション 及び Z又は用途を隣接 LSR 1 1間で交換して、 正しくセッションを確立し、誤接 続を防止する （なお、 当該 TLVはィニシャライゼーシヨンメッセージに追加して も良い)。
具体的には、 セッションのタイプ又は用途を示す「セッションタイプ (Session TYPE) TLVJ 及び/又はこのセッションを使用するアプリケーションのタイプ を示す 「アプリケーションタイプ (Application TYPE) TLVJ 及び/又はこのセ ッシ aンの名前を示す「セッション名 (Session name) TLVj を新しく定義し（こ れらの TLVを 「セッションタイプ情報」 と総称する）、 例えば、 ハローメッセ一 ジ又はィニシャライゼーションメッセージにより当該 TLVを（ラベル配付用シグ ナリング処理部 1 1 8を通じて） 送受信し、 一致する場合だけハロー隣接又は LDPセッションを確立する。 ただし、 「Session name TLV」 については、 これを 保守運用面でだけで使用する場合は、 この限りではない。
つまり、本実施形態のラベル配付用シグナリング処理部 1 1 8は、 LDPメッセ ージとしてのハローメッセージに 「セッションタイプ情報」 を付加することによ り、 隣接 LSR との間のハロー隣接確立時に当該情報を交換するハローメッセ一 ジ処理部としての機能を有していることになる。
また、 ィニシャライゼーシヨンメッセージの共通パラメータ TLV(Common Session Parameters TLV)でセッシヨンのタイプ又は用途を示す 「セッションタ ィプ」 及び/又は当該セッションを使用するアプリケーションのタイプを示す 「Application TYPE」 及び/又は当該セッションの名前を示す 「Session namej パラメータを新しく定義して、 上記パラメータを送受信し、 一致する場合だけハ ロー隣接又は LDP セッションを確立するようにすることもできる。 ただし、 「Session name TLV」については、これを保守運用面でだけで使用する場合は、 この限りではない。
つまり、 この場合、 ラベル配付用シグナリング処理部 1 1 8は、 LDPメッセー ジとしてのィニシャライゼーシヨンメッセージに 「セッションタイプ情報」 を付 加することにより、 隣接 LSR との間のハロー隣接確立時に当該情報を交換する ィニシャライゼーシヨンメッセージ処理部としての機能を有していることになる。 なお、 以上のメッセージはトンネル LSP中で送受信しても良いし、 IP経路で 送受信しても良い。
以下に、 上記メッセージ、 TLV、 パラメータの追加、 変更例を示す。
<3> 「セッションタイプ （Session TYPE) TLV」 の新規定義例
図 4に「セッションタイプ TLVJの新規定義例を示す。この図 4に示すように、 「セッションタイプ TLV」 には、 TLVの種別を表示する 「TLV種別」 フィール ド 2 1 , 「長さ (Length)」 フィ—ノレド 2 2及び 「セッションタイプ (Session TYPE) J フィールド 2 3を用意し、 「TLV種別」 フィールド 2 1には当該 TLVの 種別 （この場合は 「セッショ ンタイプ TYPE」） タイプを示す情報、 「長さ (Length) J フィールド 2 2には当該 TLVの長さを示す情報、 「セッションタイ プ （Session TYPE) J フィールド 2 3には、 設定するセッシヨンのタイプを示す 情報をそれぞれ設定する。
例えば、 " 0 " で通常の LDPセッション （basic ldp session)、 " 1 " で制御メ ッセージ交換用の LSP のための LDP セッション （ldp session for control message)、 " 2 " でデータ交換用の LSPのための LDPセッション （ldp session for data plane message) を表すものとする （他はリザーブとする）。 なお、 「Session TYPEJ は図 4に示すようにサポードするタイプを複数設定すること が可能である。
<4> 「アプリケーションタイプ （Application TYPE) TLVJ の新規定義例 次に、 図 5に 「アプリケーションタイプ TLV」 の新規定義例を示す。 この図 5 に示すように、 「アプリケーション TLV」には、 「TLV種別」フィールド 3 1， 「長 さ (Length) J フィールド 3 2及び 「アプリケーションタイプ」 フィールド 3 3 を用意し、 「TLV種別」 フィールド 3 1には当該 TLVの種別 （この場合は 「アブ リケ一シヨン」） を示す情報、 「長さ （Length)」 フィールド 3 2には当該 TLVの 長さを示す情報、 「アプリケーションタイプ」 フィールド 3 3には、設定するセッ ションのタイプを示す情報をそれぞれ設定する。
例えば、 " 0 " で "unknown", " 1 " でトラフィックエンジニアリングセッシ ヨン、 " 2，， で 「Martini L2 VPNJ セッションをそれぞれ表すものとする （他は リザーブとする）。 なお、 本 「Application TYPE」 も図 5に示すようにサポート するタイプを複数設定することが可能である。
<5> 「セッション名 (Session Name) TLVj の新規定義例
図 6は「セッション名 TLV」の新規定義例を示す図で、この図 6に示すように、 「セッション名 TLVJ には、 TLV種別フィールド 4 1， 「長さ （Length)」 フィ 一ノレド 4 2及び 「Session Name J フィ一ノレド 4 3を用意し、 「Session Name TLVJ フィールド 4 1には当該 TLVのタイプ (この場合は 「Session NameJ ) を 示す 「TLV種別」） を示す情報、 「長さ （Length)」 フィールド 4 2には設定する セッションを示す情報 （キャラクタ列） を設定する。
<6> 「ハローメッセージ」 の拡張例
次に、図 7及ぴ図 8に「ハローメッセージ (Hello Message) Jの拡張例を示す。 これらの図 7及び図 8に示すように、 「ハローメッセージ」 には、メッセージ種別 〔この場合は Hello (0x0100) ) を示すメッセージ種別フィールド 5 1， 当該メ ッセージの長さ （Message Length) を示すメッセージ長フィーノレド 5 2 , メッ セージ IDフィ一ノレド 5 3 ,共通ノヽ口一ノ ラメータ (Common Hello Parameters) TLV フィールド 5 4及びォプショナルバラメ一タフィールド 5 5が用意されて おり、 さらに、 共通ハローパラメータ TLVフィールド 5 4には、パラメータ種別 (共通ハローパラメータ） を示すフィールド 5 4 1 , 当該共通ハローパラメータ TLVフィールド 5 4の長さ （フィールド長） を設定する長さフィールド 5 4 2及 び保持時間 （Hold Time) フィールド 5 4 3等が用意されている。
そして、 本実施形態では、 上記のォプシ aナルパラメ一タフィールド 5 5に設 定する情報 （オプショナルパラメータ） を拡張し、 既存のパラメータ （「IPv4 Transport Address (0x0401)」， 「Configu tion (0x0402)」， 「IPv6 Transport Address (0x0403) J ) に加えて、 「 Session TYPE」 （ Session TYPE TLV) , 「Application TYPE」 （Application TYPE TLV) , 「 Session Name」 (Session Name TLV) の各情報を設定可能としている。
このような拡張オプショナルパラメータをもつハローバケツトを隣接 LSR 1 1間で交換することによって、 確立する LDPセッションのアプリケーション及 び/又は用途をハロー隣接確立時に明示的に指定することが可能となる。
<7> 「ィニシャライゼーシヨン (Initialization Message) J の拡張例 1 次に、 図 9に 「ィニシャライゼーシヨンメッセージ」 の拡張例 1を示す。 この 図 9に示すように、 「ィニシャライゼーション」 には、 メッセージ種別 〔この場合 は "Initialization (0x0200) "] を示すメッセージ種別フィールド 6 1 , 当該メッ セージの長さ （Message Length) を示す ッセージ長フィールド 6 2 , メッセ 一ジ ID フィ一ノレ K 6 3 , 共通セッシ a ンパラメータ ( Common Session Parameters) TLV フィールド 6 4及びォプショナルバラメ一タフィールド 6 5 が用意されている。
また、図 1 0に示すように、上記共通セッションパラメータ TLVフィールド 6 4には、 さらに、 パラメータ種別 (共通セッションパラメータ) を示すフィール ド 6 4 1 , 当該共通セッションパラメータ TLVフィールド 6 4の長さ （フィール ド長） を設定する長さフィールド 6 4 2 , プロ トコルバ一ジヨンフィ一ノレド 6 4 3 , キープアライブタイム（Keep Alive Time)フィールド 6 4 4及び受信側 LDP 識別子 （Receiver LDP Identifier) フィールド 6 4 5が用意されている。
そして、 本実施形態では、 この図 1 0に示すように、 当該共通セッションパラ メータ TLVフィールド 6 4に、 「セッションタイプ （Session TYPE)」 フィール ド 6 4 6， 「アプリケーシヨンタイプ（Application TYPE)」 フィールド 6 4 7及 び 「セッション名 （Session Name)」 フィールド 6 4 8を追加定義し、 「セッシ ヨンタイプ」， 「アプリケーションタイプ」， 「セッション名」 の各情報を設定可能 としている。
このような拡張コモンセッションパラメータをもつィニシャライゼーションメ ッセージを隣接 LSR 1 1間で交換することによって、 確立する LDPセッション のアプリケーション及び Z又は用途を丄 DPセッション確立時に明示的に指定す ることが可能となる。
<8> 「ィニシャライゼ一ションメッセージ」 の拡張例 2
なお、 確立する LDPセッションのアプリケーション及び又は用途を明示的に 指定するのにィニシャライゼーションメッセージを用いる場合、 そのォプショナ ルパラメータを拡張してもよレ、。 即ち、 オプショナルパラメータとして、 既存の ノ ラメータ (「ATM Session Parameters (0x0501) J， Frame Relay Session (0x0502) J 等） に加えて、 前記の Γ Session TYPEj (Session TYPE TLV) , 「Application TYPEj (Application TYPE TLV) , 「Session NameJ (Session Name TLV) の各情報を設定可能とする。
このようにしても、 確立する LDPセッションのアプリケーション及び/又は 用途を LDPセッション確立時に明示的に指定することが可能となる。
以上のようにして、 同一隣接 LSR 1 1間で、 同じラベル空間を使用した LDP セッションを複数設定することを可能となるとともに、 その LDPセッションの 用途及び Z又はアプリケーションを明示的に指定 (識別)することが可能となる。
③次に、 本実施形態では、 プロビジョエング情報 (Provisioning Information) を LDP メッセージで送受信することにより、 リモート側の情報を自動的に入手 〔又は削除（撤回）〕するとともに、誤配線及び Z又はプロビジョニング情報の設 定ミスを検出できるようにもなつている。ここで、当該プロビジョニング情報は、 既存メッセージ (例えば、ィニシャライゼーションメッセージ) に新規 TLVとし て追加しても良いし、 メッセージ自体を新しく定義しても良い。 ただし、 追加/ 変更の可能性が高い情報については、 新規メッセージ又はァドレスメッセージを 用いるのが望ましい。 これにより、プロビジョニングの誤りによる MPLS及びァ プリケーシヨンの誤動作を事前にチェックでき、 防止することができる。
その具体例を以下の <9>， <10>, <11>, <12>に示す。 なお、 かかる機能も、 ラベル配付用シグナリング処理部 1 1 8の機能拡張によって実現されている。
<9> 「プロビジョニング情報 （Provisioning Information) TLVJ の新規定義 例 図 1 1に、 「プロビジョユング情報 TLV」 の新規定義例を示す。 この図 1 1に 示すように、 「プロビジョニング情報 TLV」 には、 TLV種別 （この場合は 「プロ ビジョニング情報」 ) を示す TLV種別フィールド 7 1， 本 「プロビジョニング情 報 TLV」 の長さを示す TLV長 （Length) フィールド 7 2 , プロビジョニングパ ラメータ （Provisioning Parameter) フィールド 7 3が用意され、 プロビジョニ ングパラメータとして、 図 1 2に示すようなフォーマットを有する rpwパラメ 一タ （Pseudo Wire Parameter) TLVJ を複数設定できるようになつている。 なお、 この図 1 2に示すように、 Γρ\νパラメータ TLVJ には、 さらに、 TLV 種別 （この場合は 「PWパラメータ」） を示す TLV種別フィールド 7 3 1， 当該 TLV長を示す TLV長フィール 7 3 2及び 「PW FEC TLVJ フィールド 7 3 3 を用意し、 複数の 「PW FEC TLV」 （前述した 「Mai'tini」 ドラフトで定義されて いる） の設定が可能になっている。
このような「プロビジョニング情報 TLV」 を隣接 LSR 1 1間で交換することに より、 ； PW単位で、 相手 （リモート） 側のプロビジョニング情報を自動的に入手 〔又は削除 （撤回）〕 するとともに、誤配線及び/又はプロビジョニング情報の設 定ミスを検出することが可能となる。 つまり、 本実施形態のラベル配付用シダナ リング処理部 1 1 8は、 LDP のエンティティに関するプロビジョニング情報を LDPメッセージに付加して隣接 LSRとの間で交換するプロビジョニング情報交 換処理部としての機能も果たしていることになる。
<10> 「ィニシャライゼーションメッセージ」 の拡張例
なお、 プロビジョニング情報の交換にィニシャライゼーションメッセージを用 いる場合には、 例えば、 そのオプショナルパラメータ （図 9参照） を拡張して、 既存のパラメータ （「ATM Session Parameters (0x0501)」， 「 Frame Relay Session (0x0502)」 等） 及び前記の 「セッションタイプ」 （セッションタイプ TLV) , 「アプリケ一ションタイプ」 (アプリケーションタイプ TLV) , 「セッショ ン名」 （セッション名 TLV) に加えて、 さらに 「プロビジョニング情報」 （ 「プロ ビジョニング情報 TLV」 の各情報を設定可能とする。
このような拡張ォプショナルバラメータをもつィニシャライゼーシヨンメッセ ージを隣接 LSR 1 1間で交換することによって、 LDPセッション確立の際に事 前に、相手（リモート）側のプロビジョニング情報を自動的に入手〔又は削除（撒 回）〕するとともに、誤配線及び Z又はプロビジョニング情報の設定ミスを検出す ることが可能となる。
く 11〉 「プロビジョニングメッセージ」 の新規追加例
次に、 プロビジョニング情報を交換するための専用のメッセージ （プロビジョ ニングメッセ一ジ） を新規に追加定義する （ラベル配付用シダナリング処理部 1 1 8で生成する）場合は、例えば図 1 3に示すようなフォーマツトとする。即ち、 このプロビジョニングメッセージには、 メッセージ種 S （この場合は 「プロビジ ョユング」) を示すメッセージ種別フィールド 8 1 , 当該メッセージの長さを示す メッセージ長フィールド 8 2 , メッセージ ID フィールド 8 3及びプロビジョ二 ング情報 TLVフィールド 8 4を用意し、 当該フィールド 8 4に自 LSR 1 1のプ 口ビジョニング情報 （プロビジョニング情報 TLV) を設定することにより、 隣接 LSR 1 1間でのプロビジョユング情報を交換することが可能となる。
<12> 「アドレスメッセージ (Address Message) J の拡張例
次に、 LDP のァドレスメッセージ (LDP確立後に交換されるメッセ一ジ) を 用いてプロビジョニング情報の交換を行なう場合は、例えば図 1 4に示すように、 メッセージ種別 (この場合は 「ア ドレス (Address) J を表示) を示すメッセージ 種別フィールド 9 1 ,当該メッセージの長さを示すメッセージ長フィールド 9 2， メッセージ IDフィールド 9 3， アドレスリス ト (Address List) TLVフィール ド 9 4 , オプショナルパラメータフィーノレド 9 5を有するァドレスメッセージの 当該ォプショナルパラメ一タフィールド 9 5に設定すべきパラメータを拡張し、 プロビジョユング情報として 「プロビジョユング情報 TLV」 を設定可能とする。 これにより、 LDPセッション確立後においても、 適宜に、 相手 （リモート） 側 のプロビジョニング情報を自動的に入手 〔又は削除 （撤回）〕 するとともに、 誤配 線及び/又はプロビジョニング情報の設定ミスを検出することが可能となる。 な お、 上記プロビジョニング情報の交換はィニシャライゼーションメッセージ及ぴ ァドレスメッセージのいずれか一方を用いて行なっても良いし、 双方を用いて行 なっても良い。
④次に、上記の項目①及ぴ②により前述したように追加定義した TLVを使用し て、 隣接 LSR 1 1の該当するアプリケーション及び/又は用途に対する LDPセ ッシヨンを明示的に正しく設定するとともに、 リモート側のプロビジョニング情 報を自動入手 〔又は削除 （撤回)〕 することにより、 当該情報のプロビジョユング を不要とする手法について、図 1 5に示すシーケンス図を参照しながら説明する。 なお、 ここでは、 「Martini」 ドラフトに対する拡張を例にして、 ハロー P舞接の自 動検出の方法を説明する。
図 1 5に示すように、 まず、 MPLS 網 1に接続する 「Martini」 ドラフトによ る MPLS L2 VPNを実装した隣接 PE 1 1間 〔LSR#1 (能動）、 LSR#2 (受動） とする〕 で、 互いのラベル配付用シグナリング処理部 1 1 8の機能により、 ハロ ーメッセージを交換する (ステップ S 1 )。 その際、 項目く 1>， <2>により前述し たように当該ハローメッセージの LDP識別子又は LDP PDUを拡張してセッシ ヨン IDを付与しておくことで、 LSR#1-LSR#2間で複数の LDPセッションを明 示的に指定'識別することが可能となる。なお、当該セッシヨン IDは、隣接 LSR#1, LSR#2において、 図 1 5中に示す全てのメッセージに付与しておくことで、 同一 ラベル空間を使用する複数の LDPセッションの確立が可能となる。
また、 項目く 3>， <4>, <5>, <6>により前述したように、 上記ハローメッセ一 ジに、 「セッションタイプ TLV」 及び/又は 「アプリケーションタイプ TLVj 及 び/又は 「セッション名 TLVJ を付与しておくことにより、 確立する LDPセッ ションを使用するアプリケーション及び Z又はその用途を明示的に指定 ·識別す ることが可能となり、 アプリケーション及び Z又はその用途を明示したハロー隣 接を正しく確立することが可能となる （ステップ S 2 )。
さらには、 上記ハローメッセージ交換前に、 ラベル配付用シグナリング処理部 1 1 8の機能（予め隣接 LSRとの間にトンネル LSPを設定するトンネル LSP設 定部としての機能） により、 隣接 LSR(PE) 1 1間でフルメッシュの LSP(トンネ ル LSP)を通常の LSPで設定して隣接 LSR 1 1間を論理的に直接接続し（これに より、 トンネル LSPを使用して基本ディスカバリメカニズムを使用することが可 能となる）、 上記ハローメッセージに、 項目く 3>, <4>, <5>により前述した 「セ ッシヨンタイプ TLV」及び Z又は「アプリケーションタイプ TLV」及び/ /又は「セ ッシヨン名 TLV」 を付与し、 宛先ァドレスをマルチキャスト (224,0.0.2) とした ハローメッセージを互いに送信 （基本ディスカバリ） することにより、 リモート 側の 「Martini」 方式を処理する LDPエンティティのアドレスを自動検出するこ とが可肯 となる。
さて、 上述のごとくハロー隣接が確立すると、 隣接 LSR#1-LSR#2間では、 次 に、 TCPメッセージの交換 （ステップ S 3〜S 5 ) により、 トランスポートコネ クションを確立し（ステップ S 6 )、互いのラベル配付用シグナリング処理部 1 1 8の機能により、 ィニシャライゼーシヨンメッセージの交換を行なう (ステップ S 7， S 8 )。その際、当該ィニシャライゼーションメッセージを、項目く 3>， <4>, <5>, <7>, <8>により前述したように拡張しておくことで、 当該フェーズにおレ、 ても、 当該 LDP セッションを使用するアプリケーシヨン及び/又はその用途を 明示的に指定 ·識別することが可能となる。
また、 上記ィ二シャライゼーシヨンメッセ一ジに、 項目 <9>， <10>により前述 したように、 「プロビジョユング TLV」 を追加してプロビジョニング情報を交換 することにより、 MPLS処理部 1 1 5において、 リモート側のプロビジョニング 情報を入手 〔又は削除 （撤回）〕 するとともに、 プロビジョ二ング情報のアンマッ チをチェックアウトして保守者等に通知することが可能となる。 また、 リモート 偶 Jのアドレス設定も不要となる。 なお、 MPLS処理部 1 1 5において、 プロビジ ョニング情報のアンマッチが検出された場合、その後の処理は続行しても良いし、 中止しても良い。 また、 交換する情報によっては、 アドレスメッセージに新 TLV を追加することで対応しても良い。
さらに、項目く 11>にて前述したようにプロビジョニングメッセージを新たに追 加定義して 「プロビジョユング情報 TLV」 を追加した当該プロビジョエングメッ セージを LDPセッション確立後に隣接 LSR#1-LSR#2間で交換することにより、 LDPセッション確立後にも、 リモート側のプロビジョニング情報を入手〔又は削 除（撤回）〕 するとともに、 プロビジョニング情報のアンマッチをチェックアウト して保守者等に通知することが可能となる。 なお、 この場合も、 その後の処理は 続行しても良いし、 中止しても良い。
さて、 上記ィ-シャライゼーシヨンメッセージの交換により、 隣接 LSR#1-LS R2 が、 それぞれ、 当該ィニシャライゼーシヨンメッセージのセッションパラメ ータを許容すると、 以後、 キープアライブメッセージを定期的に発行して自己が 正常に動作していることをリモート側に通知する （ステップ S 1 1， S 1 2 )。 以 上により、 隣接 LSR#1-LSR#2間で、 同一ラベル空間を使用した複数の LDPセ ッションが、 当該セッションを使用するアプリケーション及び Z又はその用途で 正しく確立される。
その後、 隣接 LSR#1-LSR#2は、 MPLSパケット (ラベル付きパケット） のフ ォヮーディンングデシジョンに使用する LDP ピアのァドレスをァドレスメッセ ージによって交換する （ステップ S 1 4 ) 力 その際、 項目く 12>にて前述したよ うにァドレスメッセージを拡張して新 TLVを追加することで、ィニシャライゼ一 シヨンメッセージを利用した場合と同様に、 リモート側のプロビジョニング情報 を入手 〔又は削除 （撤回）〕 するとともに、 プロビジョニング情報のアンマッチを チェックアウトして保守者等に通知することが可能となる。 なお、 この場合も、 アンマッチが検出された後の処理は続行しても良いし、 中止しても良い。 また、 当該セッション中で変更されなレ、情報については、 ィニシャライゼーションメッ セージに 「プロビジョユング情報 TLV」 を追加して対応しても良い。
そして、 隣接 LSR#1-LSR#2は、 互いに受信したアドレスメッセージの情報内 容に基づいてラベルマッピングメッセ一ジを送受してラベル配付 （ラベルマッピ ング） を行なう (ステップ S 1 5， S 1 6 )。 これにより、以降、各 LSR#1, LSR#2 において、配付されたラベルを付加された MPLSパケッ卜のフォヮ一ディングが 可能となる。
以上のように、 本実施形態によれば、 同一隣接 LSR間で、 同じラベル空間を 使用した LDPセッションを複数設定することが可能となり、 また、その用途（ァ プリケーション） を明示的に示すことが可能となるので、 LDPセッションを誤り なく接続して、 誤プ口ビジョニング及びそれによるセッションの誤接続をセッシ ヨン確立時に早期に検出することができる。
また、プロビジョニングの誤りによる MPLS及びァプリケーションの誤動作を 防止し、 さらに、 リモート側 LSRに関するプロビジョニング情報を自動検出し、 リモート側情報のプロビジョニングを無くし （あるいは減らし） て、 プロビジョ ユングミスによる誤接続または誤動作を削減することもできる。 したがって、 MPLS及び Z又は GMPLS及び/又は前者を拡張したプロトコル を実装した装置 （パケット中継装置 ZTDM中継装置 Z光波長中継装置等） で構 成したネットワークにおいて、 MPLS及び/又は GMPLS及び Z又は前者を拡張 したプロトコルを使用したアプリケーションを実現する場合のネットワーク設計 の容易化， 柔軟性向上及び保守/運用 Z管理効率などの向上が期待できる。 また、 ブリッジをベースとした装置に MPLS (例えば、 「Martini」 方式） を実 装する場合など、 実装コストやハードウェアの制約等の面から、 機能的に制限を もつ装置同士または機能的に制限をもつ装置と汎用的に機能を装備した装置との 間の相互接続性の向上に効果が大きい。 産業上の利用可能性
以上のように、本発明によれば、ラベルスィツチネットワークの設計の容易化， 柔軟性向上及び保守 Z運用/管理効率などの向上が期待できるとともに、 機能的 に制限をもつ装置同士または機能的に制限をもつ装置と汎用的に機能を装備した 装置との間の相互接続性の向上が期待できるので、 ネットワーク通信分野におい て極めて有用であると考えられる。

Claims

請 求 の 範 囲
1 . 所定のラベル配付プロトコルにより配付されたラベル情報に従って受信パ ケットをルーティングする機能を有する複数のラベルスィツチノードをそなえて 成るラベルスィッチネットワークにおいて、
該ラベル配付プロトコルにより隣接ラベルスィツチノード間で送受されるメッ セージに、 同一隣接ラベルスィツチノード間に確立すべきセッションを識別する セッション識別情報を付加して該メッセージの送受を行ない、
同一隣接ラベルスィツチノードが、 それぞれ、 該セッション識別情報に基づい て、 該同一隣接ラベルスィツチノード間に同一ラベル空間で使用する複数セッシ ヨンを確立することを特徴とする、 ラベノレスイッチネットワークにおけるセッシ ョン確立方法。
2 . 所定のラベル配付プロトコルにより配付されたラベル情報に従って受信パ ケットをルーティングする機能を有する複数のラベルスイッチノードをそなえて 成るラベルスィッチネットワークにおいて、
該ラベル配付プロ トコルにより隣接ラベルスィツチノード間で送受されるメッ セージに、 該隣接ラベルスィツチノード間で確立すベきセッションを使用するァ プリケーション及びその用途のいずれか一方又は双方を明示するセッシヨンタイ プ情報を付加して該メッセージの送受を行ない、
該隣接ラベルスィツチノードが、 それぞれ、 該セッションタイプ情報に基づい て、 該隣接ラベルスイッチノード間に該セッシヨンタイプ情報に応じた該セッシ ョンを確立することを特徴とする、 ラベルスィツチネットワークにおけるセッシ ョン確立方法。
3 . 所定のラベル配付プロトコルにより配付されたラベル情報に従って受信パ ケットをルーティングする機能を有する複数のラベルスィツチノードをそなえて 成るラベルスィツチネットワークにおいて、
該ラベル配付プロトコルにより隣接ラベルスィツチノード間で送受されるメッ セージに、 同一隣接ラベルスィツチノード間に確立すべきセッションを識別する セッション識別情報と、 当該セッションを使用するアブリケーション及びその用 途のいずれか一方又は双方を明示するセッションタイプ情報とを付加して該メッ セージの送受を行ない、
該同一隣接ラベルスィッチノードが、 それぞれ、 該セッション識別情報及び該 セッションタイプ情報に基づいて、 該同一隣接ラベルスィツチノード間に同一ラ ベル空間で使用する、 該セッシヨンタイプ情報に応じた複数のセッションを確立 することを特徴とする、 ラベルスィツチネットワークにおけるセッション確立方 法。
4 . 該メッセージとしてのハローメッセージに該セッションタイプ情報を付加 することにより、 該隣接ラベルスィツチノード間のハロー隣接確立時に該セッシ ョンタイプ情報を該隣接ラベルスィツチノード間で交換することを特徴とする、 請求の範囲第 2項又は第 3項に記載のラベルスィツチネットワークにおけるセッ ション確立方法。
5 . 該メッセージとしてのィニシャライゼーシヨンメッセ一ジに、 該セッショ ンタイプ情報を付加することにより、 該隣接ラベルスィッチノード間のセッショ ン確立時に該セッシヨンタイプ情報を該隣接ラベルスイッチノード間で交換する ことを特徴とする、 請求の範囲第 2項又は第 3項に記載のラベルスィツチネット ワークにおけるセッション確立方法。
6 . 隣接ラベルスィッチノ一ド間で該セッションを確立する際に、 該ラベル配 付プロトコルのエンティティに関するプロビジョニング情報を該メッセージに付 加して交換することを特徴とする、 請求の範囲第 1項〜第 3項のいずれか 1項に 記載のラベルスイッチネットワークにおけるセッション確立方法。
7 . 所定のラベル配付プロトコノレにより配付されたラベル情報に従って受信パ ケットをルーティングする機能を有するラベルスイッチノードであって、 該ラベル配付プロトコルにより隣接ラベルスィツチノードとの間で送受すべき メッセージに、 同一隣接ラベルスィツチノード間に確立すべきセッションを識別 するセッション識別情報を付カ卩して該メッセージの送受を行なうラベル配付プロ トコル処理部と、
該ラベル配付プ口 トコル処理部で該隣接ラベルスィツチノードから受信した該 ラベル配付プロトコルのメッセージに付加されたセッション識別情報に基づいて、 該隣接ラベルスイッチノードとの間に同一ラベル空間で使用する複数セッシヨン の確立を制御するセッション確立制御部とをそなえたことを特徴とする、 ラベル スィツチノード。
8 . 所定のラベル配付プロトコルにより配付されたラベル情報に従って受信パ ケットをルーティングする機能を有するラベルスィツチノードであって、
該ラベル配付プロトコノレにより隣接ラベルスィツチノードとの間で送受すべき メッセージに、 該隣接ラベルスィッチノ一ドとの間で確立すベきセッションを使 用するアプリケーション及びその用途のいずれか一方又は双方を明示するセッシ ョンタイプ情報を付加して該メッセージの送受を行なうラベル配付プロトコノレ処 理部と、
該ラベル配付プ口トコル処理部で該隣接ラベルスイッチノードから受信した該 ラベル配付プロ トコノレのメッセージに付加されたセッションタイプ情報に基づい て、 該隣接ラベルスイッチノードとの間に該セッシヨンタイプ情報に応じた該セ ッションの確立を制御するセッション確立制御部とをそなえたことを特徴とする、 ラベノレスィツチノード。
9 . 所定のラベル配付プ口トコノレにより配付されたラベル情報に従つて受信パ ケットをルーティングする機能を有するラベルスィツチノードであって、
該ラベル配付プロトコルにより隣接ラベルスィッチノ一ドとの間で送受すべき メッセージに、 該隣接ラベルスィッチノードとの間に確立すべきセッションを識 別するセッション識別情報と、 当該セッションを使用するアプリケーシヨン及び その用途のいずれか一方又は双方を明示するセッションタイプ情報とを付加して 該メッセージの送受を行なうラベル配付プロ トコル処理部と、 該ラベル配付プロトコル処理部で該隣接ラベルスィツチノードから受信した該 ラベル配付プロトコルのメッセージに付加されたセッション識別情報及ぴセッシ ョンタイプ情報に基づいて、 該隣接ラベルスィツチノードとの間に同一ラベル空 間で使用する、 該セッシヨンタイプ情報に応じた複数セッションの確立を制御す るセッション確立制御部とをそなえたことを特徴とする、ラベルスイッチノード。
1 0 . 該ラベル配付プロトコル処理部が、
該ラベル配付プロトコルの該メッセージとしてのハローメッセージに該セッシ ョンタイプ情報を付加することにより、 該隣接ラベルスィッチノ一ドとの間のハ 口一隣接確立時に該セッシヨンタイプ情報を該隣接ラベルスイッチノードとの間 で交換するハローメッセージ処理部をそなえて構成されたことを特徴とする、 請 求の範囲第 8項又は第 9項に記載のラベルスィツチノード。
1 1 . 該ラベル配付プロトコル処理部が、
該ラベル配付プロトコルの該メッセージとしてのィニシャライゼーションメッ セージに、 該セッションタイプ情報を付加することにより、 該隣接ラベルスィッ チノ一ドとの間のセッション確立時に該セッションタイプ情報を該隣接ラベルス ィツチノードとの間で交換するィニシャライゼーションメッセージ処理部をそな えて構成されたことを特徴とする、 請求の範囲第 8項又は第 9項に記載のラベル スィツチノード。
1 2 . 該ラベル配付プロトコル処理部が、
該ラベル配付プロ トコルのェンティティに関するプロビジョニング情報を該メ ッセージに付加して交換するプロビジョニング情報交換処理部をそなえて構成さ れたことを特徴とする、 請求の範囲第 7項〜第 9項のいずれか 1項に記載のラベ ノレスィツチノード。
1 3 . 該ラベル配付プロトコル処理部が、 該隣接ラベルスィッチノードとの間で該セッション確立制御部により該セッシ ョンを確立する際に、 予め当該隣接ラベルスィツチノードとの間にトンネルラベ ルスィツチパスを設定するトンネルラベルスィツチパス設定部をそなえ、 該プ口ビジョニング情報交換処理部が、 ' 該トンネルラベルスィツチパス設定部により設定された該トンネルラベルスィ ツチパスを通じて該プロビジョニング情報の付加された該メッセージを交換する ように構成されたことを特徴とする、 請求の範囲第 1 2項に記載のラベルスイツ チノード。
1 4 . 該プロビジョニング情報交換処理部が、
該隣接ラベルスィツチノード間で該ラベル配付プ口トコルに従って送受するィ ニシャライゼーションメッセージ及びァドレスメッセージのいずれか一方又は双 方に、 該プロビジョユング情報を転送する TLV (Type/Length/Value)を追加する ように構成されたことを特徴とする、 請求の範囲第 1 2項又は第 1 3項に記載の ラベルスイッチノード。
1 5 . 該プ口ビジョニング情報交換処理部が、
該ラベル配付プロトコルにおいて新規に定義した該プロビジョニング情報の転 送用のメッセージを交換するように構成されたことを特徴とする、 請求の範囲第 1 2項又は第 1 3項に記載のラベルスィツチノード。
1 6 . 該プロビジョニング情報交換処理部が、
該ラベル配付プロトコルにおいて新規に定義した該プロビジョニング情報の撤 回用のメッセージを交換するように構成されたことを特徴とする、 請求の範囲第 1 2項又は第 1 3項に記載のラベルスィツチノード。
PCT/JP2003/008710 2003-07-09 2003-07-09 ラベルスイッチネットワークにおけるセッション確立方法及びラベルスイッチノード WO2005006670A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/JP2003/008710 WO2005006670A1 (ja) 2003-07-09 2003-07-09 ラベルスイッチネットワークにおけるセッション確立方法及びラベルスイッチノード
JP2005503838A JP4109692B2 (ja) 2003-07-09 2003-07-09 ラベルスイッチネットワークにおけるセッション確立方法及びラベルスイッチノード
US11/262,188 US20060062218A1 (en) 2003-07-09 2005-10-28 Method for establishing session in label switch network and label switch node

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2003/008710 WO2005006670A1 (ja) 2003-07-09 2003-07-09 ラベルスイッチネットワークにおけるセッション確立方法及びラベルスイッチノード

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/262,188 Continuation US20060062218A1 (en) 2003-07-09 2005-10-28 Method for establishing session in label switch network and label switch node

Publications (1)

Publication Number Publication Date
WO2005006670A1 true WO2005006670A1 (ja) 2005-01-20

Family

ID=34044594

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2003/008710 WO2005006670A1 (ja) 2003-07-09 2003-07-09 ラベルスイッチネットワークにおけるセッション確立方法及びラベルスイッチノード

Country Status (3)

Country Link
US (1) US20060062218A1 (ja)
JP (1) JP4109692B2 (ja)
WO (1) WO2005006670A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008139553A1 (ja) * 2007-05-01 2008-11-20 Fujitsu Limited Mplsトンネルの認識方法及び装置
JP2015512601A (ja) * 2012-04-04 2015-04-27 アルカテル−ルーセント ネットワークノードにおいてマルチプルラベル配布プロトコル（ｌｄｐ）インスタンスを実装するシステムおよび方法

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0667276U (ja) * 1993-03-09 1994-09-22 株式会社丸山製作所 作業車
US7447212B2 (en) * 2003-09-03 2008-11-04 At&T Intellectual Property I, L.P. Method and system for automating membership discovery in a distributed computer network
CN100473069C (zh) * 2004-07-12 2009-03-25 中兴通讯股份有限公司 支持伪线标签反射的二层虚拟专网设备和组网方法
US8089964B2 (en) 2005-04-05 2012-01-03 Cisco Technology, Inc. Transporting multicast over MPLS backbone using virtual interfaces to perform reverse-path forwarding checks
US7756125B2 (en) * 2005-08-05 2010-07-13 Telefonaktiebolaget Lm Ericsson (Publ) Method and arrangement for routing pseudo-wire encapsulated packets
US8107473B2 (en) 2006-03-16 2012-01-31 Cisco Technology, Inc. Automation fallback to P2P LSPs for mLDP built multipoint-trees
US7852841B2 (en) * 2005-11-04 2010-12-14 Cisco Technology, Inc. In-band multicast signaling using LDP
US20070127479A1 (en) * 2005-12-05 2007-06-07 David Sinicrope A method and arrangement for distributed pseudo-wire signaling
US8934486B2 (en) * 2006-03-16 2015-01-13 Cisco Technology, Inc. System and method for implementing multicast over a label-switched core network
US8199761B2 (en) * 2006-04-20 2012-06-12 Nokia Corporation Communications multiplexing with packet-communication networks
US7899044B2 (en) * 2006-06-08 2011-03-01 Alcatel Lucent Method and system for optimizing resources for establishing pseudo-wires in a multiprotocol label switching network
US7983274B2 (en) * 2006-12-21 2011-07-19 Verizon Patent And Licensing Inc. Performance monitoring of pseudowire emulation
US7907603B2 (en) * 2007-04-26 2011-03-15 Cisco Technology, Inc. Acceleration of label distribution protocol (LDP) session setup
US20110228744A1 (en) * 2008-09-09 2011-09-22 Nokia Siemens Networks Oy Application Identification in Mobile Networks
US8199679B2 (en) * 2009-05-29 2012-06-12 Alcatel Lucent Enterprise virtual private LAN services
CN102668488A (zh) * 2009-12-30 2012-09-12 中兴通讯股份有限公司 多协议标签交换系统中网络拓扑的更新方法及系统
US9112723B2 (en) * 2010-06-30 2015-08-18 Cisco Technology, Inc. Service node using services applied by an application node
EP2461501A1 (en) * 2010-12-01 2012-06-06 Alcatel Lucent Tunnel follow-up message for transparent clock
US20130022041A1 (en) * 2011-07-18 2013-01-24 Sriganesh Kini Signaling a label switched path (lsp) tunneling model
US9042369B2 (en) * 2013-03-13 2015-05-26 Alcatel Lucent System and method for reflecting FEC route information
US9769068B2 (en) * 2013-09-30 2017-09-19 Cisco Technology, Inc. Virtual LDP session
US9602354B1 (en) * 2014-06-30 2017-03-21 Juniper Networks, Inc. Applications-aware targeted LDP sessions
US11483236B2 (en) * 2020-03-31 2022-10-25 Nokia Solutions And Networks Oy Stateless multicast based on network label space

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001339463A (ja) * 2000-05-25 2001-12-07 Fujitsu Ltd 通信システム及び通信装置
JP2002208939A (ja) * 2000-12-08 2002-07-26 Alcatel Canada Inc Ａｔｍプラットフォームにおけるｍｐｌｓ実装

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6678264B1 (en) * 1999-06-30 2004-01-13 Nortel Networks Limited Establishing connections with a pre-specified quality of service across a communication network
CA2327918A1 (en) * 2000-12-08 2002-06-08 Alcatel Canada Inc. System and method of operating a communication network associated with an mpls implementation on an atm platform
US7184434B2 (en) * 2002-03-28 2007-02-27 Tropic Networks Inc. Label distribution protocol supporting multiple classes of service in a multi protocol label switching (MPLS) network, methods and MPLS network using thereof

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001339463A (ja) * 2000-05-25 2001-12-07 Fujitsu Ltd 通信システム及び通信装置
JP2002208939A (ja) * 2000-12-08 2002-07-26 Alcatel Canada Inc Ａｔｍプラットフォームにおけるｍｐｌｓ実装

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008139553A1 (ja) * 2007-05-01 2008-11-20 Fujitsu Limited Mplsトンネルの認識方法及び装置
JP2015512601A (ja) * 2012-04-04 2015-04-27 アルカテル−ルーセント ネットワークノードにおいてマルチプルラベル配布プロトコル（ｌｄｐ）インスタンスを実装するシステムおよび方法

Also Published As

Publication number Publication date
JPWO2005006670A1 (ja) 2006-08-31
US20060062218A1 (en) 2006-03-23
JP4109692B2 (ja) 2008-07-02

Similar Documents

Publication Publication Date Title
CN111865796B (zh) 用于网络业务的路径计算单元中央控制器（pcecc）
JP4109692B2 (ja) ラベルスイッチネットワークにおけるセッション確立方法及びラベルスイッチノード
US8155000B2 (en) Technique for enabling traffic engineering on CE-CE paths across a provider network
US9306855B2 (en) System and method for using label distribution protocol (LDP) in IPv6 networks
US7733883B2 (en) Method for implementing a virtual leased line
KR100693059B1 (ko) Ｍｐｌｓ 기반의 ｖｐｎ 제공 장치 및 방법
JP3760167B2 (ja) 通信制御装置、通信ネットワークおよびパケット転送制御情報の更新方法
WO2005101730A1 (fr) Systeme et procede permettant d&#39;assurer une qualite de service dans un reseau virtuel prive
JP2012507909A (ja) Ｒｓｖｐ−ｔｅを用いるシングルルートマルチポイントサービスにおけるマルチキャスト及び双方向ユニキャストのシグナリング
US10432516B2 (en) Pseudowire servicing across multiple administrative systems using border gateway protocol-link state
WO2010057383A1 (zh) 一种实现业务转发的方法、系统和设备
WO2009076848A1 (zh) 一种pbb网络中自动拓扑发现及资源管理的方法和装置
US20050198301A1 (en) Apparatus and method for layer-2 and layer-3 VPN discovery
Ward et al. MPLS architectural considerations for a transport profile
KR20070064845A (ko) 엠피엘에스 망에서 대표 레이블 스위치 경로 생성 방법
Zhang et al. LDP Extensions for UNI 1.0
Bahoo et al. Segment Routing over IPv6 (SRv6)
Zhang et al. Contribution Number: OIF2000. 140.1
Li et al. Integrated Control Plane for IP Enabled Optical Network
KR20070061933A (ko) 엠피엘에스 브이피엔을 이용한 가입자간 포인트 투 포인트서비스 제공 장치 및 방법

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP US

WWE Wipo information: entry into national phase

Ref document number: 2005503838

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 11262188

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 11262188

Country of ref document: US