Source: http://www.google.com/patents/US6144661?dq=5095480
Timestamp: 2014-03-13 09:51:07
Document Index: 166219374

Matched Legal Cases: ['arty 202', 'arty 101', 'arty 201', 'arty 203', 'arty 203', 'arty 201', 'arty 101', 'arty 203', 'arty 203', 'arty 203', 'arty 203', 'arty 201', 'arty 202', 'arty 203', 'arty 101', 'arty 203', 'arty 203', 'arty 101', 'arty 101', 'arty 101', 'arty 202', 'arty 202', 'arty 101', 'arty 201', 'arty 101']

Patent US6144661 - Network node apparatus and virtual connection control method for providing ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA system for forming one point-to-multipoint connection provides various service attributes in an ATM network in response to differences in service attributes requested by receiving parties or differences in available resources. A network node sets up an output VC (Virtual Channel) link to be connected...http://www.google.com/patents/US6144661?utm_source=gb-gplus-sharePatent US6144661 - Network node apparatus and virtual connection control method for providing various service attributes in multicast communicationAdvanced Patent SearchPublication numberUS6144661 APublication typeGrantApplication numberUS 08/794,704Publication dateNov 7, 2000Filing dateFeb 4, 1997Priority dateFeb 5, 1996Fee statusLapsedPublication number08794704, 794704, US 6144661 A, US 6144661A, US-A-6144661, US6144661 A, US6144661AInventorsYasuhiro Katsube, Takeshi Saito, Hisako TanakaOriginal AssigneeKabushiki Kaisha ToshibaExport CitationBiBTeX, EndNote, RefManPatent Citations (4), Referenced by (34), Classifications (17), Legal Events (6) External Links: USPTO, USPTO Assignment, EspacenetNetwork node apparatus and virtual connection control method for providing various service attributes in multicast communicationUS 6144661 AAbstract A system for forming one point-to-multipoint connection provides various service attributes in an ATM network in response to differences in service attributes requested by receiving parties or differences in available resources. A network node sets up an output VC (Virtual Channel) link to be connected to an input VC link, the VC links being parts of a point-multipoint connection, receives a new VC link set-up request, and adds to the point-multipoint connection, in response to the new VC link set-up request, new output VC link with service attribute different from that of the input VC link.
According to one method, the new receiving party transmits a Leaf.sub.-- Setup.sub.-- Request of the leaf-initiated-join type, that is specified by the ATM signaling, to the sending party. According to another method, when the sending party and the receiving party have the Internet protocol (IP) layer as an upper layer (i.e., are IP hosts or routers), the new receiving party transmits to the sending party or to some server a request message to join an IP multicast group or an IP multicast routing information exchange message. In this case, the sending party transmits an Add.sub.-- Party of the ATM signaling for requesting participation of the new receiving party, when it learns that the above IP message has been transmitted by the new receiving party. The Leaf.sub.-- Setup.sub.-- Request and the Add.sub.-- Party are examples of a new output VC link creation request for the corresponding ATM node.
Let us assume that the new receiving party 202 does not request any specific QoS, which means that it desires a "best effort" communication. Information indicating whether or not a new receiving party is requesting QoS and if so, the details of this QoS, may be contained in the Leaf.sub.-- Setup.sub.-- Request as an ATM level requested service attribute. Alternatively, a control message containing ATM level requested service attribute information may be sent separately from the Leaf.sub.-- Setup.sub.-- Request, but in association therewith, by the new receiving party, or by the sending party that has become aware of the QoS request of the receiving party through RSVP, etc. Each ATM node can be notified of the requested service attribute for the new receiving party, with the above Leaf.sub.-- Setup.sub.-- Request or the control message.
Also, when the sending party learns a QoS request of the new receiving party, either by the QoS request in the IP multicast group join request message, etc., or by the RSVP message indicating the QoS request, the receiving party may transmit the Add.sub.-- Party including the ATM level requested service attribute. Alternatively, a control message containing ATM level requested service attribute information may be sent separately from the Add.sub.-- Party, but in association therewith, by the new receiving party or by the sending party. Each ATM node can be notified of the requested service attribute for the new receiving party with the above Add.sub.-- Party or the control message.
The Add.sub.-- Party is transferred first on existing leaves from the sending party, and then transferred as a VC setup request from a branch point where a new leaf is to be set up. This process continues up to the new receiving party.
The following description takes as an example the case where the ATM signaling Add.sub.-- Party is employed and the requested service attribute information is included in the Add.sub.-- Party, referring to FIG. 2 and FIG. 3. In this case, sending party 101 uses an Add.sub.-- Party request to addition of a new receiving party to the p-p VC destined to receiving party 201 whose call identifier is 10. UBR (Unspecified Bit Rate) service is specified as the requested service attribute contained in the Add.sub.-- Party because the new receiving party requests best-effort communication, ATM node 301, which has received the Add.sub.-- Party, determines its route based on the address of the receiving party to be added and/or its requested service attribute, and obtains the VPI/VCI value (in this case 80/40) in output link 2 to form a new leaf to the downstream ATM node 303.
The next case described is where a further new receiving party 203 (FIG. 2(c)) is added to this p-mp VC (call identifier=10). It will be assumed that this receiving party 203 requests a prescribed QoS just as receiving party 201. Sending party 101 uses an ATM Add.sub.-- Party to request the addition of a new receiving party 203 to p-mp VC whose call identifier is 10. The sending party specifies an attribute such as CBR (Constant Bit Rate) service and cell loss rate of 10-8 as the service attribute requested for the receiving party 203.
ATM node 301 receiving the Add.sub.-- Party determines that its downstream ATM node is 303 (i.e., output link is 2), based either on the address and/or the requested service attribute of the receiving party to be added, or on the routing information explicitly indicated in the Add.sub.-- Party. Also, node 301 checks for a leaf corresponding to the call identifier 10 from output link 2 to downstream ATM node 303, referring to a resource management table (FIG. 3(b)), and recognizes that one already exists (VPI/VCI=80/40).
Also, ATM node 301 produces a new entry in the service attribute management table to store the service attribute of new receiving party 203 (for example, call identifier=10, output link=2, VPI/VCI=80/40, service attribute={CBR, 10 Mbps, CLR=10-81}). Then, ATM node 301 sends an Add.sub.-- Party to downstream ATM node 303.
ATM node 303, which has received the Add.sub.-- Party obtains VPI/VCI onto downstream ATM node 305, reserves the resource (in this case 10 Mbps), and updates the entries of both the resource management table and the service attribute management table. Then, ATM node 303 sends a VC setup request to downstream ATM node 305.
FIG. 4 shows a processing algorithm in an ATM node when a receiving party is to be added as described above. First, the ATM node receives an Add.sub.-- Party regarding an existing VC from an upstream ATM node or sending party in signaling message processor unit 11 (S1). The Add.sub.-- Party includes the address of the new receiving party and the ATM level requested service attribute. Next, the Add.sub.-- Party is handed over to connection state management unit 12. Connection state management unit 12 interrogates routing control unit 13 about a downstream ATM node identified by the destination (receiving party) address in the Add.sub.-- Party and/or the requested service attributes, or by a request for a specific route. Routing control unit 13 then determines the downstream ATM node (S2).
Connection state management unit 12 checks whether a VC leaf corresponding to the Add.sub.-- Party already exists in the output link to the downstream ATM node (S3). If not (S3 No), unit 12 interrogates admission control unit 14 whether the resource calculated from the requested service attribute can be allocated. Admission control unit 14 uses the information of link state management table 15 to decide whether or not it can be allocated, and notifies connection state management unit 12 of this result. If connection state management unit 12 is notified that addition of a leaf is possible, it provisionally enters information of the new leaf including the allocated resource into resource management table 16 (S9), provisionally enters information concerning the new receiving party into service attribute management table 17 (S10), and sends a VC setup request to the downstream node (S11).
Then, regardless of the result of step S4 check, connection state management unit 12 provisionally enters the information concerning the new receiving party into service attribute management table 17 (S7), and transfers the Add.sub.-- Party to the downstream node (S8). Finally, when connection state management unit 12 receives from downstream a notification that VC-setup/party-addition has been completed or refused (S12), the provisional entry/alteration is confirmed (S13) or canceled (S14).
The case will be described where a further new receiving party 203 is added to the p-mp VC to QoS requesting receiving party 201 and non-QoS receiving party 202. It will be assumed that this receiving party 203 requests a prescribed QoS just as in the case of 201. Sending party 101 requests the addition of a new receiving party 203 to p-mp VC whose call identifier is 10 using an ATM signaling Add.sub.-- Party. The sending party specifies an attribute such as CBR (Constant Bit Rate) service and cell loss rate of 10.sup.-8 as the service attribute requested for the receiving party.
ATM node 301, which has received the Add.sub.-- Party, determines that its downstream ATM node is 303 (i.e., output link is 2), based either on the address and/or the requested service attribute of the receiving party to be added, or on the routing specifying information in the Add.sub.-- Party. Also, node 301 checks for a leaf corresponding to the call identifier 10 from output link 2 to downstream ATM node 303, referring to a resource management table (FIG. 3(b)), and recognizes one already exists (VPI/VCI=80/40).
It is not necessary according to this method for ATM node 301 to maintain the service attribute management table, so ATM node 301 sends an Add.sub.13 Party to downstream ATM node 303 promptly. ATM node 303, which has received the Add.sub.13 Party, obtains VPI/VCI onto downstream ATM node 305, reserves the resource (in this case 10 Mbps), and provisionally updates the resource management table (no service attribute management table). Then, ATM node 303 sends a VC setup request to downstream ATM node 305.
When receiving party 203 decides to admit this VC setup, it transmits a VC setup ack message to sending party 101 through ATM nodes 306, 305, 303 and 301. The name of the message changes into Add.sub.13 Party ack upstream of the ATM node 303. The ack message is used for confirming the provisional contents of the management tables.
First, ATM node 303 in FIG. 2(c) receives from ATM node 305 the VC setup ack message including the information indicating the resource actually allocated or to be allocated based on the requested service attribute to the leaf between ATM nodes 305 and 306. Next, the ATM node 303 determines the largest of the resource indicated by the VC setup ack and the resource actually allocated (or to be allocated based on the service attribute), to the leaf between ATM nodes 303 and 304, which is the other leaf of the p-mp VC. Then, ATM node 303 enters the information indicating the determined largest resource into an Add.sub.13 Party ack. to be sent to upstream node 301.
In this example, the information included in the VC setup ack. received from ATM node 305 indicates the resource of 10 Mbps, and the resource allocated between ATM nodes 303 and 304 is zero, so the ATM node 303 enters the resource of 10 Mbps into the Add.sub.13 Party ack. to upstream node 301. ATM node 301, which received the Add.sub.13 Party ack, executes the same procedure. It determines the information (the resource of 10 Mbps) to be entered into an Add.sub.13 Party ack to be sent to sending party 101. It does so using the information (the resource of 10 Mbps) contained in the received Add.sub.13 Party ack and the resource (10 Mbps) allocated to the leaf between ATM nodes 301 and 302 stored in the resource management table. When the ack message has reached sending party 101 in this way, a p-mp VC branching at ATM nodes 301 and 303 is formed.
The chief difference from the conventional method is that it is possible to accommodate a new receiving party, even if the ATM node which has received a VC setup or an Add.sub.13 Party finds that the requested service attribute cannot be satisfied due to bandwidth insufficiency. The system can avoid denying entirely the participation request of the new receiving party, and can provide minimum connectivity by performing service with a bandwidth (or without bandwidth) within a range that can be allocated.
Next, the case will be described where a new receiving party 202 is added to this p-p VC (call identifier=10). Let us assume that the new receiving party 202 requests a specific QoS just as in the case of 201. Sending party 101 requests addition of a new receiving party to the p-p VC destined to receiving party 201 whose call identifier is 10, by an ATM signaling Add.sub.13 Party. It specifies in the Add.sub.13 Party for example CBR service of peak rate 10 Mbps as the requested service attribute.
ATM node 301 receiving the Add.sub.-- Party determines its route based on the address of the receiving party to be added and/or its requested service attribute, and obtains the VPI/VCI value (in this case 80/40) in output link 2 to form a new branching leaf to the downstream ATM node 303. It further attempts to reserve the necessary resource, but it cannot do so due to bandwidth insufficiency.
Conventionally, at this point, an Add.sub.13 Party denial notification would be sent upstream. However, in the present method, ATM node 301 allocates some resource by lowering the resource for the new leaf so far as is permitted by the remaining bandwidth in the output link. Alternatively, ATM node 301 decides to allocate no resource to the new leaf.
Alternatively, sending party 101 may create a field indicating which is preferable in a case of bandwidth insufficiency: (i) some connection with nonsatisfactory resource to the receiving party, or (ii) no connection, in the Add.sub.13 Party or VC setup request to be sent.
First of all, the ATM node receives an Add.sub.13 Party from an upstream ATM node or sending party (S1001). The Add.sub.13 Party includes the address of the new receiving party, the ATM level requested service attribute, and the actually allocated resource at the upstream node. Next, the downstream node on the route is identified and the resource to be allocated is determined (S1002). The resource to be allocated is the minimum of the necessary resource calculated from the requested service attribute and the resource allocated at the upstream node.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5153877 *Apr 19, 1990Oct 6, 1992Kabushiki Kaisha ToshibaPacket network with communication resource allocation and call set up control of higher quality of serviceUS5592476 *Apr 14, 1995Jan 7, 1997Hewlett-Packard LimitedAsynchronous transfer mode switch with multicasting abilityUS5742772 *May 5, 1997Apr 21, 1998Lucent Technologies Inc.Resource management system for a broadband multipoint bridgeUS5777986 *Aug 16, 1996Jul 7, 1998Motorola, Inc.Method and apparatus for controlling quality of service in an ATM network* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS6246669 *Nov 17, 1998Jun 12, 2001Cisco Technology, Inc.Method and system for optimizing connection set-up operations in a high speed digital networkUS6304579 *Jul 2, 1998Oct 16, 2001Ricoh Company, Ltd.Method and apparatus for sending a 1�N communication messageUS6400689 *Aug 10, 1998Jun 4, 2002Fujitsu LimitedNetwork service management apparatusUS6496504 *Aug 6, 1998Dec 17, 2002Ricoh Company, Ltd.Smart allocation of bandwidth for multiple independent calls on a digital networkUS6529498 *Oct 13, 1998Mar 4, 2003Cisco Technology, Inc.Routing support for point-to-multipoint connectionsUS6556569 *Jan 6, 1999Apr 29, 2003Fujitsu LimitedSystem for managing connection-oriented communication interface with flexible virtual channel associationUS6563798Jun 29, 1998May 13, 2003Cisco Technology, Inc.Dynamically created service class-based routing tablesUS6600724Apr 28, 1998Jul 29, 2003Cisco Technology, Inc.Routing table structuresUS6600735 *Mar 1, 1999Jul 29, 2003Hitachi, Ltd.Internet telephone connection method, bandwidth controller and gate keeperUS6625605 *May 23, 2000Sep 23, 2003Oki Electric Industry Co, Ltd.Service attribute management systemUS6678264 *Jun 30, 1999Jan 13, 2004Nortel Networks LimitedEstablishing connections with a pre-specified quality of service across a communication networkUS6714547 *Feb 3, 2000Mar 30, 2004Nec CorporationQuality-ensuring routing techniqueUS6717920Jan 14, 2003Apr 6, 2004Cisco Technology, Inc.Dynamically created service class-based routing tablesUS6785274Oct 7, 1998Aug 31, 2004Cisco Technology, Inc.Efficient network multicast switching apparatus and methodsUS6804236Oct 7, 2002Oct 12, 2004Cisco Technology, Inc.Efficient network multicast switching apparatus and methodsUS6963725 *Aug 13, 2001Nov 8, 2005Pioneer CorporationInformation communication terminal apparatusUS7050441 *Nov 29, 2001May 23, 2006Pts CorporationMethod and apparatus for hybrid communication networkUS7139275 *Jul 16, 2001Nov 21, 2006Cisco Technology, Inc.Providing differentiated services on ATM switched virtual circuits when transporting IP packetsUS7215674 *Apr 22, 2002May 8, 2007Cisco Technology, Inc.Supporting applications sensitive to data loss on switched virtual circuits (SVCs)US7272134Jun 10, 2003Sep 18, 2007Hitachi, Ltd.Internet telephone connection method, bandwidth controller and gate keeperUS7324526 *Oct 11, 2002Jan 29, 2008Cisco Technology, Inc.Efficient processing of connection control messages in managing virtual circuits using signaling protocolsUS7483380 *Aug 30, 2004Jan 27, 2009Motorola, Inc.Method and apparatus for bandwidth managementUS7573891Mar 11, 2002Aug 11, 2009Optimal Innovations, Inc.Hybrid fiber/conductor integrated communication networksUS7643492 *Oct 15, 2001Jan 5, 2010Fujitsu LimitedNetwork bandwidth reservation methodUS7773607Dec 21, 2007Aug 10, 2010Cisco Technology, Inc.Efficient processing of connection control messages in managing virtual circuits using signaling protocolsUS7822043Apr 3, 2007Oct 26, 2010Cisco Technology, Inc.Supporting applications sensitive to data loss on switched virtual circuits (SVCs)US7869425Oct 30, 2007Jan 11, 2011Verizon Services Corp.System and method for providing requested quality of service in a hybrid networkUS8094647 *Jun 14, 2001Jan 10, 2012Verizon Services Corp.System and method for providing requested quality of service in a hybrid networkUS8174979 *Mar 28, 2008May 8, 2012Nokia Siemens Networks Gmbh & Co. KgMethod and device for controlling access to a communications networkUS8194646Oct 30, 2007Jun 5, 2012Verizon Services Corp.System and method for providing requested quality of service in a hybrid networkUS8239569 *May 1, 2006Aug 7, 2012Cisco Technology, Inc.OSPF optimization for hub and spoke environmentUS8270294 *Nov 15, 2007Sep 18, 2012Huawei Technologies Co., Ltd.Method and apparatus for implementing multicast serviceUS8306027 *Feb 22, 2008Nov 6, 2012Cisco Technology, Inc.Method for multicast load balancing in wireless LANSUS20080151807 *Feb 22, 2008Jun 26, 2008Meier Robert CMethod for multicast load balancing in wireless lans* Cited by examinerClassifications U.S. Classification370/390, 370/397, 370/399, 370/400, 370/409, 370/408International ClassificationH04Q11/04, H04L12/56, H04L12/18Cooperative ClassificationH04L2012/5642, H04Q11/0478, H04L2012/5632, H04L2012/563, H04L12/1836, H04L12/185European ClassificationH04L12/18E, H04Q11/04S2Legal EventsDateCodeEventDescriptionDec 25, 2012FPExpired due to failure to pay maintenance feeEffective date: 20121107Nov 7, 2012LAPSLapse for failure to pay maintenance feesJun 18, 2012REMIMaintenance fee reminder mailedApr 25, 2008FPAYFee paymentYear of fee payment: 8Mar 31, 2004FPAYFee paymentYear of fee payment: 4Jun 3, 1997ASAssignmentOwner name: KABUSHIKI KAISHA TOSHIBA, JAPANFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KATSUBE, YASUHIRO;SAITO, TAKESHI;TANAKA, HISAKO;REEL/FRAME:008542/0885;SIGNING DATES FROM 19970220 TO 19970305RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google